Your SlideShare is downloading. ×
  • Like
Guia de estudos   introdução à engenharia de requisitos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Guia de estudos introdução à engenharia de requisitos

  • 2,008 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,008
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
119
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Introdução à Engenharia de Requisitos conceitos, fundamentos e ferramentas Referências do BABOK 2.0 e RUP 7.1.1 Abordagem teórica e prática Rodrigo Gomes da Silva Possui trechos extraídos do BABOK / RUP
  • 2. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Sobre o Autor: Rodrigo Gomes da Silva Técnico em Processamento de Dados pelo Centro Técnico de Varginha, Bacharel em Sistemas de Informação pela Universidade do Estado de Minas Gerais, Especialista em Docência do Ensino Superior pela Faculdade do Noroeste de Minas, Especialista em Design Instrucional para EaD Virtual pela Universidade Federal de Itajubá. Possui certificação IBM RMUC 1 – Requirements Management with Use Case Part 1 e certificação IBM RMUC 2 – Requirements Management with Use Case Part 2. Atua como Analista de Requisitos na IBM do Brasil e como Professor Universitário no curso de Bacharelado em Sistemas de Informação do Centro Universitário do Sul de Minas. Atuou como Analista de Sistemas no Sindicato dos Produtores Rurais de Campanha, como Gerente de Tecnologia da Informação na Santa Casa de Misericórdia da Campanha, como Professor Universitário na Faculdade Cenecista de Varginha, Universidade Vale do Rio Verde e Faculdades Integradas Paiva de Vilhena. Além de lecionar no curso de Sistemas de Informação, atuou nos cursos de Administração, Automação Industrial, Ciência da Computação, Processos Gerenciais e Pedagogia. 2
  • 3. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Sumário 1. Melhores Práticas da Engenharia de Software 1.1 Sintomas dos Problemas de Desenvolvimento de Software 1.2 As Seis Melhores Práticas da Engenharia de Software 1.2.1 Melhor Prática 1 – Desenvolvimento Iterativo 1.2.2 Melhor Prática 2 – Gestão de Requisitos 1.2.3 Melhor Prática 3 – Arquitetura Baseada em Componentes 1.2.4 Melhor Prática 4 – Modelagem Visual – UML 1.2.5 Melhor Prática 5 – Verificação Contínua da Qualidade 1.2.6 Melhor Prática 6 – Gestão de Configuração e Mudança 2. RUP e as Melhores Práticas da Engenharia de Software 2.1 RUP e as Melhores Práticas da Engenharia de Software 2.1.1 Definição de Processos no RUP 2.1.2 Fases do Ciclo de Vida do RUP 3. Engenharia de Requisitos 3.1 Engenharia de Software 3.2 O que são Requisitos? 3.3 Tipos de Requisitos 3.4 Engenharia de Requisitos 3.4.1 Produção de Requisitos 3.4.1.1 Levantamento 3.4.1.2 Registro 3.4.1.3 Verificação 3.4.1.4 Validação 3.4.2 Gerência de Requisitos 3.4.2.1 Controle de Mudanças 3.4.2.2 Gerência de Configuração 3.4.2.3 Rastreabilidade 3.4.2.4 Gerência de Qualidade de Requisitos 4. Disciplina de Requisitos 4.1 O que os Requisitos de Software Especificam? 4.2 Definições Importantes 4.3 Alguns Exemplos 4.4 Dificuldade em Gerenciar Requisitos 4.5 Qualidade dos Requisitos 4.6 Disciplina de Requisitos no RUP 4.7 Principais Artefatos da Disciplina de Requisitos 5. Análise do Problema 5.1 Entendendo o Problema 5.2 Passos para Análise do Problema 5.3 Identificando as Restrições do Sistema 5.4 Identificando os Limites do Sistema 5.5 Needs (necessidades) dos Stakeholders e do Negócio 5.6 Features (características) do Software 5.7 Requisitos do Software 5.8 Capturar Vocabulário Comum 6. Entendendo a Necessidade do Stakeholder 6.1 Capturando Necessidades 6.2 Atividades e Artefatos 6.3 Problemas a Serem Encontrados 6.4 Artefato Stakeholder Request (Pedidos dos Envolvidos) 6.5 Elicitação de Requisitos 6.5.1 Brainstorming 6.5.1.1 Vantagens do Bradinstorming 6.5.1.2 Desvantagens do Brainstorming 6.5.2 Análise de Documentos 6.5.2.1 Vantagens da Análise de Documentos 6.5.2.2 Desvantagens da Análise de Documentos 6.5.3 Workshop de Requisitos 7 7 7 8 10 10 11 11 11 12 12 16 17 19 19 21 22 23 25 25 25 25 26 26 26 26 27 27 28 28 28 29 29 30 31 33 34 34 40 40 41 41 42 43 43 44 44 44 44 45 47 47 48 48 48 49 50 50 3
  • 4. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 6.5.3.1 Vantagens do Workshop de Requisitos 6.5.3.2 Desvantagens do Workshop de Requisitos 6.5.4 Entrevistas 6.5.4.1 Vantagens da Entrevista 6.5.4.2 Desvantagens da Entrevista 6.5.5 Observação 6.5.5.1 Vantagens da Observação 6.5.5.2 Desvantagens da Observação 6.5.6 Outras Técnicas Importantes 6.5.7 Obstáculos da Elicitação de Requisitos 7. Atividades de Requisitos 7.1 Especificação de Requisitos 7.2 Requisitos Funcionais 7.2.1 Exemplos de Requisitos Funcionais 7.3 Requisitos Não Funcionais 7.3.1 Exemplos de Requisitos Não Funcionais 7.4 Planejar o Processo de Gerenciamento de Requisitos 7.4.1 Repositório 7.4.2 Rastreabilidade 7.4.3 Selecionar Atributos dos Requisitos 7.4.4 Processo de Priorização dos Requisitos 7.4.5 Gerenciamento de Mudanças 7.4.6 Gerenciar o Escopo e os Requisitos da Solução 7.4.7 Gerenciar de Conflitos 7.5 Apresentando Requisitos para Revisão 7.5.1 Aprovação 7.6 Comunicar os Requisitos 7.7 Regras de Negócio 7.7.1 Recomendações para Regras de Negócio 7.7.2 Tabelas de Decisão 7.7.3 Se-Então-Senão 8. Principais Artefatos do Time de Requisitos 8.1 Especificação de Requisitos de Software 8.2 Especificações Suplementares 8.3 Glossário 8.4 Modelo de Casos de Uso 8.5 Pedido dos Envolvidos 8.6 Plano de Gerenciamento de Requisitos 8.7 Visão 9. UML 9.1 O que é a UML 9.2 Para que serve a UML 9.3 Falta de Alinhamento entre Cliente, Analista e Time 9.4 Aprovação do Cliente 9.5 Modelagem 9.6 Motivação para Utilização de Modelagem 9.7 Tipos de Diagramas da UML 9.8 Características da UML 10. Diagrama de Atividades 10.1 O que é o Diagrama de Atividades 10.2 Elementos do Diagrama de Atividades 10.2.1 Estado Inicial 10.2.2 Estado Final 10.2.3 Atividade 10.2.4 Transição entre Estados de Atividades 10.2.5 Rais 10.2.6 Ramificações 10.2.7 Sincronizações 11. O Modelo de Casos de Uso 11.1 O que é o Modelo de Casos de Uso 51 51 52 53 53 54 55 56 56 56 57 57 57 58 58 58 58 59 59 59 61 62 63 64 64 65 65 65 66 67 68 68 68 69 69 70 71 72 73 74 74 74 74 75 76 77 77 78 79 79 79 80 80 80 81 82 82 83 84 84 4
  • 5. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 11.2 Diagrama de Casos de Uso 11.2.1 Elementos do Diagrama de Caso de Uso 11.2.1.1 Ator 11.2.1.2 Papél 11.2.1.3 Caso de Uso 11.2.1.4 Relacionamentos do Caso de Uso 11.2.1.5 Associação 11.2.1.6 Inclusão 11.2.1.7 Extensão 11.2.1.8 Generalização 12. Especificação de Casos de Uso 12.1 O que é a especificação de um Caso de Uso 12.2 Benefícios dos Casos de Uso 12.3 Desvantagens dos Casos de Uso 12.4 Quando Utilizar Casos de Uso 12.5 Nomeando Casos de Uso 12.6 Elaboração em Fases 12.7 Sessões da Especificação de Casos de Uso 12.7.1 Introdução 12.7.2 Breve Descrição 12.7.3 Diagrama de Casos de Uso 12.7.4 Atores 12.7.5 Pré-Condições 12.7.6 Pós-Condições 12.7.7 Fluxo de Eventos 12.7.7.1 Fuxo Principal 12.7.7.1.1 Início do Fluxo Principal 12.7.7.1.2 Tratamento de Condições 12.7.7.1.3 Referenciando Outros Casos de Uso 12.7.7.2 Fluxo Alternativo 12.7.7.2.1 Identificando Fluxos Alternativos 12.7.7.3 Fluxo de Exceção 12.7.7.3.1 Identificando Fluxos de Exceção Referências Bibliográficas Links para Templates de Artefatos do RUP 84 85 85 86 86 87 87 88 88 90 90 90 90 91 91 92 93 94 94 95 95 95 96 96 97 98 98 98 99 99 101 101 101 103 104 5
  • 6. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Lista de Figuras Figura 1.1: Desenvolvimento em Cascata Figura 1.2: Desenvolvimento Iterativo Figura 2.1: RUP – Gráfico de Baleias Figura 2.2: Desenvolvimento Iterativo e Incremental Figura 2.3: Relação entre Ferramentas e as Seis melhores Práticas da Engenharia de Software Figura 3.1: Custo de manutenção de sistemas Figura 3.2: Fatores Críticos no Desenvolvimento de Software Figura 3.3: Engenharia de Requisitos Figura 4.1: Fluxo de Atividades de Requisitos do RUP Figura 4.2: Papéis e artefatos da disciplina de requisitos do RUP Figura 5.1: Representação do Problema Figura 5.2: Relação espaço do problema X espaço da solução Figura 9.1: Falta de alinhamento entre Cliente, Analista e Time de Desenvolvimento Figura 9.2: Domínio da Complexidade Figura 10.1: Estado Inicial do Diagram de Atividades Figura 10.2: Estado Final do Diagrama de Atividades Figura 10.3: Exemplo de Atividade Figura 10.4: Transição entre Estados de Atividades Figura 10.5: Diagrama de Atividades com Raias Figura 10.6: Diagrama de Atividades com Ramificação Figura 10.7: Diagrama de Atividades com Forking e Joining Figura 11.1: Ator Figura 11.2: Papéis de um Ator Figura 11.3: Interação entre Ator e Casos de Uso Figura 11.4: Associação entre Ator e Caso de Uso Figura 11.5: Relacionamento Inclusão Figura 11.6: Relacionamento Extensão Figura 11.7: Utilização de Inclusão e Extensão Figura: 11.8 Herança entre Atores Figura 12.1: Elaboração de casos de uso de forma iterativa Figura 12.2: Pré e Pós-Condição 9 9 13 14 16 20 21 24 32 33 35 36 75 76 80 80 81 81 82 83 84 85 86 87 88 88 89 89 90 93 97 Lista de Tabelas Tabela 4.1: Principais Artefatos da Disciplina de Requisitos do RUP Tabela 5.1: exemplo de hierarquia entre Needs, Features e Requisitos Tabela 5.2: Needs identificadas Tabela 5.3: Features identificadas Tabela 5.4: Requisitos identificados Tabela 7.1: Regra de Negócio em Tabela de Decisão Lista de Quadros Quadro 5.1: Exemplo de descrição do problema Quadro 5.2: Desejo dos Stakeholders Quadro 6.1: Conteúdo do Documento Stakeholder Request Quadro 7.1: Regra de Negócio em Se-Então-Senão Quadro 12.1: Fluxo Principal Quadro 12.2: Caso de uso com referência para outro caso de uso Quadro 12.3: Fluxo Alternativo Quadro 12.4: Retorno no Fluxo Alternativo Quadro 12.5: Retorno no Fluxo Alternativo II Quadro 12.6: Exemplo de Fluxo Alternativo Quadro 12.7: Exemplo de Fluxo de Exceção 33 36 38 38 39 67 37 37 46 68 99 99 100 100 100 101 102 6
  • 7. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 1. Melhores Práticas da Engenharia de Software 1.1 Sintomas dos Problemas de Desenvolvimento de Software A Engenharia de Software é a área da computação que tem como objetivo garantir a especificação e o desenvolvimento de software com qualidade. O processo de desenvolvimento de software, muitas vezes considerado caótico, pode gerar frustração e insatisfação se não for conduzido adequadamente. O simples “codificar por codificar” nos leva ao desenvolvimento de soluções inadequadas, que não atendem as reais necessidades de nossos clientes e aumentam a necessidade de constantes manutenções, que elevam os custos e ultrapassam os prazos, gerando problemas para os clientes, usuários e para o time de desenvolvimento. Na busca pelos sintomas dos problemas de desenvolvimento de software, observou-se que, em muitos casos, o problema está em: • falta de compreensão das necessidades do negócio; • falta de entendimento das necessidades dos usuários; • desenvolvimento de soluções com módulos não integrados; • dificuldade de manutenção do software construído; • falta de coordenação do time de desenvolvimento. Todos estes fatores acabam por gerar uma má experiência por parte do usuário, uma vez que o projeto não produz os resultados desejados. 1.2 As Seis Melhores Práticas da Engenharia de Software Diante do atual cenário de desenvolvimento de software, a Engenharia de Software apresenta uma forma de aplicar técnicas e práticas de gerência de projetos e outras disciplinas que possibilitam o desenvolvimento de software de qualidade. Para que seja possível atingir este objetivo, os estudos da Engenharia de Software definem "Seis Melhores Práticas" a serem aplicadas no processo de desenvolvimento de software, sendo elas: • Desenvolvimento Iterativo; • Gestão de Requisitos; • Arquitetura Baseada em Componentes; 7
  • 8. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • Modelagem Visual; • Verificação Contínua da Qualidade; • Gestão de Configuração e Mudanças. 1.2.1 Melhor Prática 1 – Desenvolvimento Iterativo Durante muito tempo, o modelo de desenvolvimeno dominante foi o Desenvolvimento em Cascata. Este processo defende uma forma de trabalho sequencial, onde o desenvolvimento é visto como uma cascata, que passa de fase a fase sem nunca retornar a fase anterior. Conforme apresentado na Figura 1.1, este modelo segue as fases: • Planejamento; • Análise de Requisitos; • Design; • Codificação / Teste; • Integração de Sub-Sistemas; • Teste de Sistemas. Ao analisarmos este modelo, percebemos que o software, ou seja, o produto que o cliente espera, é entregue apenas na última etapa do processo. O modelo defende o conceito de que uma etapa apenas poderá iniciar quando a etapa anterior for concluída e verificada. No momento em que foi criado, o modelo em Cascata apresentou grande importância, pois introduziu qualidade ao desenvolvimento, demonstrando a necessidade de conduzir de forma disciplinada o processo de se produzir software. Demonstrou a importância do planejamento e gerenciamento do desenvolvimento e ainda definiu a separação entre design e codificação. No entanto, com o passar dos anos, alguns problemas deste modelo foram evidenciados: • atrasos na percepção e resolução de riscos críticos do projeto, uma vez que o cliente final tem contato com o produto apenas na última fase do processo; 8
  • 9. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • demora na entrega da solução, uma vez que o modelo não permite implantação antecipada e dificulta mudanças com o projeto em andamento. Figura 1.1: Desenvolvimento em Cascata Diante deste cenário, surge a proposta do modelo Iterativo, que aborda o desenvolvimento do produto de tal forma que seja possível melhorálo ou refiná-lo pouco a pouco. O processo de desenvolvimento acontece de forma cíclica, onde a cada iteração, a equipe identifica e especifíca os requisitos relevantes, cria um projeto de arquitetura, implementa os componentes e realiza a verificação. Se os componentes satisfazem os requisitos, o projeto prossegue com a próxima iteração, onde novamente são especificados requisitos, é definido o projeto de arquitetura, são realizadas a implementação e as verificações. A cada iteração uma nova parte do software será construída e entregue ao cliente, conforme a Figura 1.2. Figura 1.2: Desenvolvimento Iterativo 9
  • 10. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 No modelo iterativo é possível resolver maiores riscos antes de serem realizados grandes investimentos, uma vez que liberações são realizadas precocemente e o resultado do trabalho é colocada à prova pelo cliente desde o início do processo. Esta situação nos permite conhecer o feedback contínuo do cliente e dos usuários finais envolvidos e facilita o direcionamento de mudanças que se fizerem necessárias durante o projeto. 1.2.2 Melhor Prática 2 – Gestão de Requisitos A segunda melhor prática da Engenharia de Software é a Gestão de Requisitos. A Gestão de Requisitos certifica-se de resolver o problema certo e construir o sistema correto através de uma abordagem para compreenssão do problema, elicitação, organização e documentação dos requisitos. É preciso planejar, monitorar e controlar como os requisitos do software serão identificados, documentados, validados, verificados e rastreados, de forma que seja possível entender as necessidades dos stakeholdes e fazer com que o software seja desenvolvido de acordo com os requisitos documentados. É importante ainda ressaltar que durante um projeto, as necessidades podem mudar e os requisitos poderão sofrer mudanças, assim, a gestão de requisitos deve garantir que tais mudanças – Changes Requests – sejam contempladas de forma correta pelo projeto. 1.2.3 Melhor Prática 3 – Arquitetura Baseada em Componentes A terceira melhor prática da Engenharia de Software é a Arquitetura Baseada em Componentes. Esta técnica permite o reuso e customização de componentes, a utilização de componentes de software disponíveis no mercado, o aumento do encapsulamento do produto e a facilidade da evolução incremental do software. A Arquitetura Baseada em Componentes da ênfase na decomposição dos sistemas em componentes funcionais e lógicos, com interfaces bem definidas usadas para a comunicação entre os próprios componentes. Dentre as principais vantagens encontram-se a redução de esforço de desenvolvimento, maior rapidez na entrega, redução de custos e aumento da qualidade. 10
  • 11. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 1.2.4 Melhor Prática 4 – Modelagem Visual – UML A quarta melhor prática da Engenharia de Software é a Modelagem Visual. Um modelo é uma visão simplificada, que apresenta a essência do sistema, de uma perspectiva particular, permitindo que sejam escondidos detalhes não essenciais. O modelos permitem capturar e estruturar o comportamento do sistema, mostram como os elementos se encaixam e se relacionam, permitem a concistência entre concepção e implementação e possibilitam uma comunicação não-ambígua entre analistas, clientes e time de desenvolvimento, facilitando assim a verificação e validação do projeto. 1.2.5 Melhor Prática 5 – Verificação Contínua da Qualidade A quinta melhor prática da Engenharia de Software é a Verificação Contínua da Qualidade. Esta técnica permite monitorar o processo de desenvolvimento do ponto de vista da funcionalidade, usabilidade, confiança, suportabilidade e performance. A funcionalidade representa o aspecto funcional do software, testa o funcionamento preciso de cada cenário de uso da aplicação. A usabilidade avalia a interface com o usuário, testa o aplicativo a partir da perspectiva de conveniência para o usuário final. A confiabilidade refere-se a integridade, conformidade e interoperabilidade do software e avalia o comportamento consistente e previsível do software. A suportabilidade testa a capacidade de manter e apoiar o aplicativo no momento em que está em produção e a performance testa o desempenho do software em diversos cenários de utilização. 1.2.6 Melhor Prática 6 – Gestão de Configuração e Mudança A última e não menos importante melhor prática da Engenharia de Software é a Gestão de Mudanças. Esta técnica é responsável por aplicar supervisão, direção técnica e administrativa ao identificar e documentar as características funcionais e físicas de um item de configuração e controlar as mudanças dessas características. Durante o processo de desenvolvimento de software, solicitações de mudanças podem vir de várias fontes, como por exemplo, pelos clientes, marketing, codificadores, testadores ou outros 11
  • 12. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 stakeholders. As solicitações de mudanças podem ser originárias de novas características, novos requisitos, bugs ou Change Requests. É preciso que exista um canal de aprovação de tais mudanças. É necessário que o canal de aprovação receba as solicitações de mudanças e tenham condições de medir o impacto que tais mudanças provocarão no projeto, para que seja possível aprovar ou não essas solicitações antes de serem implamentadas. 2. RUP e as Melhores Práticas da Engenharia de Software 2.1 RUP e as Melhores Práticas da Engenharia de Software O Rational Unified Process ou simplesmente RUP, é um processo de desenvolvimento de software que proporciona, ao time de desenvolvimento uma abordagem disciplinada, capaz de alocar tarefas e responsabilidades aos integrantes, buscando assegurar a garantia de software de qualidade, organizar as atividades, definir papéis e atender as reais necessidades dos stakeholders dentro de um prazo previsto e um orçamento aceitável. O RUP é paltado em 2 dimensões, conforme demonstrado na figura 2.1. A primeira dimensão, representada pelo eixo horizontal da figura representa o tempo e demonstra as fases do ciclo de vida do desenvolvimento. A segunda dimensão, representada pelo eixo vertical da figura, representa os workflows do processo ou disciplinas, que agrupam atividades de acordo com a sua natureza. Enquanto a dimensão horizontal representa o aspecto dinâmico do processo, como fases, iterações e milestones, a dimensão vertical representa o aspecto estático, tais como componentes do processo, atividades, artefatos, papéis, dentre outros. A figura 2.1, também conhecida como Gráfico de Baleias, representa o relacionamento entre fases e disciplinas. 12
  • 13. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Figura 2.1: RUP – Gráfico de Baleias O gráfico de baleias explica a abordagem iterativa do RUP, onde o processo de desenvolvimento é divido nas fases: Iniciação, Elaboração, Construção e Transição. Em cada fase do ciclo de desenvolvimento pode ocorrer uma ou mais iterações, representadas no gráfico pelos indicadores E1, E2, C1, C2, CN, T1 e T2, onde N indica um número não definido de iterações. Pode-se ainda observar que em cada fase e iteração o time desenvolve atividades relacionadas às disciplinas que são representadas pelo eixo vertical, sendo: • Modelagem de Negócios; • Requisitos; • Análise e Design; • Implementação; • Teste; • Implantação; • Gerenciamento de Configuração e Mudanças; • Gerenciamento de Projetos; • Ambiente. 13
  • 14. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 O gráfico demonstra ainda a quantidade de esforço empregado em cada fase em relação a cada disciplina. Veja por exemplo que, de acordo com o gráfico a quantidade de esforço relacionado à disciplina de Modelagem de Negócios é maior na fase de Iniciação do que na fase de Transição. Por outro lado, o esforço de Implementação é maior na fase de Construção do que na fase de Iniciação. Desta forma podemos ter uma visão geral da quantidade de esforço empregada em cada fase do ciclo de vida do desenvolvimento do software. Através de seus processos, o RUP apoia o desenvolvimento com base nas seis melhores práticas da Engenharia de Software. O RUP indica que para mitigar os riscos é necessário desenvolver incrementalmente de forma iterativa, onde cada iteração pode entregar uma release executável. Um projeto baseado em desenvolvimento iterativo possui um ciclo de vida formado por várias iterações, onde uma iteração consiste em uma sequencia de atividades de Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste e Deployment, conforme demonstrado na figura 2.2. Figura 2.2: Desenvolvimento Iterativo e Incremental Os processos do RUP também apoiam o gerenciamento de requisitos, considerada a segunda melhor prática da Engenharia de Software. Gerenciar requisitos significa utilizar uma abordagem sistêmica para encontrar, documentar, organizar, disponibilizar e acompanhar as mudanças 14
  • 15. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 dos requisitos durante o ciclo de desenvolvimento do software. Esta abordagem estabelece e mantém acordos entre o cliente e o time de desenvolvimento o que acaba colaborando para a qualidade do produto final. Utilizar uma arquitetura baseada em componentes também é uma estratégia defendida e insentivada pelo RUP. Componentes são grupos coesos de código, em forma de fonte ou executável com interfaces bem definidas e que podem ser substituídos facilmente. A arquitetura baseada em componentes tende a reduzir o tamanho e a complexidade do software, permite o reuso e facilita a manutenção e/ou evolução. A quarta melhor prática da Engenharia de Software, a Modelagem Visual, também é incentivada pelo RUP, uma vez que o processo define atividades relacionadas ao uso de notações gráficas e textuais, semanticamente ricas, para capturar o projeto de software. A modelagem visual utilizando, por exemplo a UML, permite um maior nível de abstração do software o que facilita o entendimento de sistemas complexos, a exploração de alternativas do projeto, apoia a fundamentação da implementação, captura os requisitos precisamente e melhora a comunicação entre analistas, time de desenvolvimento e clientes. A verificação contínua da qualidade, elencada como a quinta melhor prática da Engenharia de Software é explicitada no RUP uma vez que o processo define avaliações de todos os artefatos em diferentes pontos do ciclo de vida de desenvolvimento. Dentre as principais atividades relacionadas à qualidade no RUP, destacam-se: a identificação de indicadores de aceitação de qualidade, a identificação de medidas apropriadas para serem usadas na avaliação e julgamento da qualidade e a identificação e endereçamento apropriado de questões que afetam a qualidade do produto mais cedo possível. Por fim, a sexta e última melhor prática da Engenharia de Software, a Gestão de Configuração e Mudanças também é apoiada pelo RUP, uma vez que o processo solicita o controle através das atividades de: • definição de um workflow de controle de mudanças; • utilização de Changes Request; 15
  • 16. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • realização de estatísticas de mudanças e análise de impacto de mudanças; • avaliação e controle da propagação de mudanças; • versionamento. Assim, podemos compreender que o RUP, através de suas ferramentas, apoia a utilização das seis melhores práticas da Engenharia de Software, conforme demonstrado na figura 2.3, que representa uma relação entre as seis melhores práticas da Engenharia de Software com as ferramentas oferecidas pelo RUP. Figura 2.3: Relação entre Ferramentas e as Seis melhores Práticas da Engenharia de Software 2.1.1 Definição de Processos no RUP Entende-se por processo um conjunto de passos ordenados que são executados para que se possa atingir alguma meta específica. Em um processo de desenvolvimento de software esta meta pode ser entendida como o desenvolvimento de um novo software ou a manutenção de um software existente. O RUP descreve uma família de processos de engenharia de software. Assim, o RUP provê uma abordagem disciplinada para a alocação de tarefas e responsabilidades. 16
  • 17. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 2.1.2 Fases do Ciclo de Vida do RUP Com o seu ciclo de vida de desenvolvimento dividido em fases, o RUP colabora de forma expressiva para o desenvolvimento incremental e iterativo. As fases do RUP diferem entre si com relação a atividades, cronogramas e duração. A divisão é feita entre as fases: Iniciação, Elaboração, Construção e Transição. Cada fase é concluída com um milestone (marco) principal. A fase de Iniciação procura obter o envolvimento de todos os envolvidos, sendo de fundamental importância para esforços de novos desenvolvimento, onde há a presença de significativos riscos para o projeto. No caso de projetos focados em software já existentes (melhorias / manutenções), a fase de iniciação se apresenta um pouco mais leve, mas mesmo assim possui o objetivo de assegurar-se de que o projeto é realmente viável. Dentre os principais objetivos da fase de iniciação estão: • Definir o escopo do projeto; • Definir uma visão operacional; • Determinar critérios de aceitação; • Discriminar os casos de uso críticos do sistema; • Identificar os principais cenários; • Evidenciar pelo menos uma arquitetura candidata para alguns dos cenários primordiais; • Estimar o custo e o cronograma geral do projeto; • Estimar os principais riscos; • Preparar o ambiente de trabalho que suportará o projeto. A fase de Elaboração tem como principais objetivos assegurar que a arquitetura, os requisitos e os planos estejam estáveis e que seja realizada a mitigação dos riscos afim de determinar custos e cronograma para a conclusão do desenvolvimento. Trabalhar arquitetura baseada em cenários e produzir um protótipo evolutivo dos componentes . Dentre as principais atividades da fase estão: • Definir, validar e criar baseline de arquitetura; • Refinar a Visão; 17
  • 18. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • Criar planos de iteração detalhados de baseline para a fase de construção; • Refinar o processo de desenvolvimento e posicionar o ambiente de desenvolvimento; • Refinar a arquitetura e selecionar componentes. A fase de Construção tem como principais objetivos esclarecer os requisitos restantes e concluir o desenvolvimento do software. A fase de construção pode ser vista como um processo de manufatura. Dentre as principais atividades da fase estão: • Gerenciamento de recursos, otimização de controle e processos; • Desenvolvimento completo do componente e teste dos critérios de avaliação definidos; • Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão. A fase de Transição tem como objetivo principal assegurar que o software esteja disponível para seus usuários. Envolvida em diversas iterações, inclui testes do produto e pequenos ajustes em função do feedback dos usuários. Dentre as principais atividades estão: • executar planos de implementação; • finalizar o material de suporte para o usuário final; • testar o produto liberado no local do desenvolvimento; • criar um release do produto; • obter feedback do usuário; • ajustar o produto com base em feedback; • tornar o produto disponível aos usuários. 18
  • 19. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 3. Engenharia de Requisitos 3.1 Engenharia de Software A Engenharia de Software é uma abordagem sistemática que disciplina e quantifica o desenvolvimento, operação e manutenção de software. É considerada sistemática uma vez que possui processos definidos. Disciplinada tendo em vista que orieta que tais processos sejam seguidos e quantificável uma vez que define um conjunto de medidas a serem aplicadas no processo. Dentre os principais objetivos da Engenharia de Software podemos citar a busca pela qualidade de software e o ganho de produtividade no desenvolvimento, operação e manutenção do software. E ainda, permite o controle sobre o desenvolvimento, custos, prazos e níveis de qualidade. A disciplina de Engenharia de Software nos oferece ferramentas e métodos capazes de organizar, orientar e discplinar o processo de desenvolvimento de software com qualidade. No entanto, o que se percebe é que o mundo do desenvolvimento de software possui diversos cenários considerados distantes do desejado e os principais motivos são a não utilização dos fundamentos da Engenharia de Software ou a má utilização dos mesmos. Dentre os principais problemas causados destacamos o elevado custo de manutenção dos sistemas. Estudos revelam que a manutenção de sistemas é mais onerosa à medida que o processo de desenvolvimento está mais avançado. Imagine um ciclo de desenvolvimento divido entre: requisitos, projeto, codificação, testes de unidades, testes do sistema e operação de campo. Se um problema a ser resolvido for detectado, por exemplo, na fase de requisitos, este terá custo 1, se por sua vez, o problema a ser resolvido for detectado na fase de operação de campo (listada como última fase do processo), a correção poderá custar até 1000 vezes mais. Observe o gráfico da figura 3.1. 19
  • 20. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Figura 3.1: Custo de manutenção de sistemas Como podemos observar, à medida em que o processo de desenvolvimento avança o custo de manutenção e correção de problemas também aumenta. A Standish Group realizou uma pesquisa com 350 companhias, onde foram analisados 8.000 projetos de software. De certa forma o resultado da pesquisa é preoculpante, uma vez que identificou-se que: • 16,2% dos projetos são finalizados com sucesso; • 52,7% dos projetos são considerados problemáticos, não cobrem todas as funcionalidades, o custo é aumentado e estão atrasados; • 31,1% dos projetos fracassam, o projeto é cancelado durante o desenvolvimento. A pesquisa realizou ainda uma análise sobre os fatores críticos para o sucesso dos projetos. O resultado é demonstrado na figura 3.2. Contudo, o que se pode observar é a necessidade de guiar o processo de desenvolvimento de software por meio de uma disciplina organizada, norteadora e que apresente métodos e ferramentas já avaliadas e validadas. É preciso organizar, controlar, dirigir e monitorar todo o 20
  • 21. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 processo, a equipe, as tarefas e a qualidade dos entregáveis, para que se possa esperar um nível mínimo de qualidade aceitável. Figura 3.2: Fatores Críticos no Desenvolvimento de Software De forma geral a Engenharia de Software pode abordar diversos assuntos, como métodos, processos, métricas, gestão de projetos e requisitos. A análise de requisitos é fundamental no processo de desenvolvimento e a Engenharia de Requisitos é vista como uma subdisciplina da disciplina de Engenharia de Software e é foco do nosso estudo. 3.2 O que são Requisitos? A literatura apresenta diversas definições para o termo requisitos de software, mas de forma geral todas expressam a mesma coisa. Requisitos de software podem ser entendidos como uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus 21
  • 22. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 objetivos. É uma descrição das funções e restrições presentes em um software. É uma condição ou capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formal. É importante entendermos que os requisitos de software descrevem o que o sistema faz e não como o sistema faz e, embora os requisitos sejam definidos junto ao cliente, nem sempre o cliente quer o que é melhor para o negócio. É papél da consultoria identificar a real necessidade do cliente. Desta forma, podemos afirmar que requisitos de software são importantes para: • Estabelecer uma base de concordância entre cliente e fornecedor; • Fornecer uma referência sobre o produto final; • Reduzir o custo de desenvolvimento. Por fim, podemos afirmar que a fase de Requisitos é sem dúvida fundamental para o sucesso de qualquer produto de software. Se o time de desenvolvimento não conhece a real necessidade do cliente é bem provavel que a solução desenvolvida não atenda todas as suas necessidades e expectativas. Corremos o risco de desenvolver uma solução bonita para o problema errado e ainda corremos o risco do cliente encarar nosso software como um produto fracassado. 3.3 Tipos de Requisitos Na literatura sobre requisitos de software podemos encontrar diversas divisões sobre tipos de requisitos, mas basicamente, precisamos compreender a existência de dois tipos, os requisitos funcionais e os requisitos não funcionais. Requisitos funcionais descrevem as funcionalidades do software, ou seja, estão diretamente ligados às funções do software, como por exemplo: • O sistema deve permitir o cadastro de cliente. 22
  • 23. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • O sistema deve permitir a geração de relatório de vendas por período. É importante salientar que, ao definirmos requisitos funcionais não devemos nos preoculpar/descrever como o software irá atender o requisito, ou como a funcionalidade será implementada, mas apenas com quais funcionalidades serão necessárias. Requisitos não funcionais descrevem condições que o software deve atender ou qualidades específicas que o software deve ter, como por exemplo: • O software deve suportar o navegador Internet Explorer 7.0 ou superior. • O tempo de resposta das consultas não deve ultrapassar 5 segundos. É importante observarmos que a descrição dos requisitos deve ser clara, objetiva e permitir a verificação. Imagine por exemplo que o requisito não funcional seja definido: “O tempo de resposta das consultas deve ser rápido”. Neste caso, quando afirmamos que a resposta do software deve ser rápida, não definimos como iremos avaliar a situação. Ser rápido pode significar uma coisa para uma pessoa e outra coisa para outra pessoa, ou seja, eu posso ter uma noção de resposta rápida diferente de outras pessoas. Portanto é importante definirmos no requisito o que é rápido, no exemplo acima definimos que rápida é a resposta em 5 segudos, ou seja, a partir desta informação teremos condições de avaliar se o software atende ou não o requisito. 3.4 Engenharia de Requisitos A Engenharia de Requisitos é uma sub-disciplina da Engenharia de Software. Sua principal responsabilidade é dividida em Produção e Gerência de Requisitos. A Produção de Requisitos é dividida em Levantamento, Registro, Validação e Verificação dos requisitos do software. A Gerência de Requisitos é dividida em Controle de Mudanças, Gerência de Configuração, 23
  • 24. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Rastreabilidade e Gerência de Qualidade, conforme demonstrado na figura 3.3. Figura 3.3: Engenharia de Requisitos Dentre os principais objetivos da Engenharia de Requisitos, podemo citar: • Estabelecer uma visão comum entre o cliente e a equipe, em relação aos requisitos que serão atendidos pelo software. • Registrar e acompanhar os requisitos ao longo de todo processo de desenvolvimento. • Documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da Engenharia de Software. • Manter planos, artefatos e atividades de software consistentes com os requisitos alocados. 24
  • 25. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 3.4.1 Produção de Requisitos A cada fase do ciclo de desenvolvimento do software produzimos um documento contendo uma representação distinta do software a ser contruído. O documento produzido é a Especificação de Requisitos, ele é a base para as próximas fases do desenvolvimento e a sua qualidade é fundamental para o sucesso do projeto. A produção de requisitos se divide em: • Levantamento; • Registro; • Verificação; • Validação. 3.4.1.1 Levantamento Levantamento de requisitos relaciona-se com à obtenção dos requisitos do software, algumas técnicas são: • Entrevistas; • Prototipação; • JAD; • Workshop. 3.4.1.2 Registro Uma vez identificados e negociados, os requisitos devem ser documentos para que possam servir de base para o restante do processo de desenvolvimento. Normalmente os requisitos serão documentados no artefato chamado Especificação de Requisitos. 3.4.1.3 Verificação A verificação examina a especificação do software, com o objetivo de assegurar que todos os requisitos foram definidos sem ambiguidade, inconsistência ou omissões, permitindo que seja possível detectar e corrigir possíveis problemas. 25
  • 26. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 3.4.1.4 Validação A validação dos requisitos tem como objetivo obter um aceite formal do cliente sob determinado artefato. 3.4.2 Gerência de Requisitos A Gerência de Requisitos responsabiliza-se pelo controle das mudanças que possam ocorrer durante o ciclo de desenvolvimento, a organização/configuração dos artefatos produzidos, a rastreabilidade entre requisitos e demais artefatos e a gestão da qualidade dos requisitos. Suas principais atividades são: • Controle de Mudanças; • Gerência de Configuração; • Rastreabilidade; • Gerência de Qualidade de Requisitos. 3.4.2.1 Controle de Mudanças Requisitos são voláteis e portanto podem sofrer mudanças ao longo do tempo. Uma maneira de organizar estas mudanças é utilizar um baseline de requisitos, o que nos mostra como os requisitos eram, o que foi introduzido e o que foi descartado. O controle de mudanças deve possuir um canal único de aprovação e deve apoiar-se em um software. 3.4.2.2 Gerência de Configuração A Gerência de Configuração estabelece normas, ferramentas e templates que permitem gerenciar de forma satisfatória os itens de configuração de um sistema. Em cada fase do processo de desenvolvimento um conjunto de itens de configuração é definido. A este conjunto é dado o nome de baseline. A baseline é guardada como uma foto dos artefatos criados até o momento. 26
  • 27. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 3.4.2.3 Rastreabilidade Rastreabilidade é a habilidade de se acompanhar a vida de um requisito em ambas as direções (partindo do requisito e chegando ao artefato ou partindo do artefato e chegando ao requisito). Dentre as diversas ferramentas utilizadas para a rastreabilidade destaca-se a Matriz de Rastreabilidade. 3.4.2.4 Gerência de Qualidade de Requisitos Como o próprio nome diz, este item preocupa-se em garantir a qualidade dos requisitos especificados. Para tanto, é necessário considerar critérios de qualidade ao trabalharmos com requisitos, são eles: • Correção; • Não ambiguidade; • Completude; • Consistência; • Verificabilidade; • Modificabilidade; • Ranqueável; • Rastreavel; • Compreensível. Correção: todos os requisitos apresentam algo que deve estar presente no sistema que está sendo desenvolvido. Os requisitos reais do usuário devem coincidir com os requisitos levantados. É preciso uma boa atividade de validação. Não Ambiguidade: é interpretado por todos os envolvidos no projeto de uma única maneira. Não gera duplo entendimento. Completude: descreve todas as demandas de interesse dos usuários. Estas demandas incluem requisitos funcionais, de desempenho, restrições, atributos e interfaces externas. Consistência: um conjunto de requisitos é considerado consistênte se nenhum sub-conjunto destes requisitos entra em conflito com os demais requisitos do sistema. 27
  • 28. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Verificabilidade: um requisito é verificável se existe uma forma efetiva, em termos de tempo e custo, para que pessoas ou ferramentas indiquem se foi atendido ou não. Modificabilidade: um conjunto de requisitos é modificável quando seu estilo e estrutura é tal que as alterações podem ser realizadas de forma simples e consistente com os demais requisitos. Ranqueável: pode ser classificado de acordo com a importância para o cliente e a estabilidade do próprio requisito. Rastreavel: a origem de cada requisito pode ser encontrada. Compreensível: o requisito deve ser facilmente compreendido por usuários e desenvolvedores. 4. Disciplina de Requisitos 4.1 O que os Requisitos de Software Especificam? Requisitos de software especificam o que o sistema deve fazer sem se preoculpar em descrever como será feito. Requisitos de software podem ainda especificar condições nas quais o software deverá operar, tecnologias utilizadas no seu desenvolvimento e padrões de qualidade. 4.2 Definições Importantes Requisitos: uma condição ou capacidade com a qual o sistema deve estar em conformidade. Gestão de Requisitos: abordagem sistemática para elicitar, organizar e documentar requisitos e ainda estabelecer e manter conformidade com o cliente e a equipe do projeto. Stakeholder Request: a expressão do estado desejado de uma das partes interessadas na solução. Feature: um serviço observável pelo qual o sistema atende as Stakeholder Request. 28
  • 29. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Requisitos Funcionais: um requisito que especifica, numa perspectiva de caixa-preta, como a solução interage com o mundo externo. Requisitos Não Funcionais: exprime, numa perspectiva de caixapreta, atributos de qualidade do software. Restrições: uma limitação de concepção do sistema ou do processo utilizado para contruir o sistema. 4.3 Alguns Exemplos Stakeholder Request • Os professores precisam ter acesso imediato à suas salas. • Os alunos precisam acessar suas notas. Feature • Uma visualização na forma de árvore permitirá o aluno visualizar as notas de cada disciplina. Requisitos Funcionais • O sistema deverá permitir que o aluno visualize as notas de suas disciplinas. Requisitos Não funcionais • O sistema deverá estar disponível 99% de 24 horas por dia por 7 dias na semana. Restrições • O sistema deverá operar em DEC VAX Main Frame. 4.4 Dificuldade em Gerenciar Requisitos Gerenciar requisitos não é uma tarefa fácil por diversos motivos, dentre eles podemos citar: requisitos não são óbvios. Ao contrário do que muitos pensam, requisitos de software não são necessariamente óbvios e 29
  • 30. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 podem se tornar ocultos se o analista de requisitos não realizar um trabalho cuidadoso, criterioso e com paciência. Requisitos de software podem possuir diversas fontes. Futuros usuários, gerentes, diretores, proprietários, integrantes da equipe de desenvolvimento são algumas fontes de requisitos a serem analisadas. Requisitos podem ainda ser levantados através da análise de documentos, leis, sistemas legados, etc. A grande quantidade de fontes onde o analista de requisitos poderá elicitá-los faz com que sua tarefa se torne ainda mais delicada, pois é preciso garantir que todos os requisitos necessários para a construção do software adequado foram levantados. Pode não ser fácil expressar os requisitos em palavras. Muitas vezes conhecemos alguma coisa/assunto mas temos dificuldade em explanar sobre eles. Isto pode acontecer no mundo dos futuros usuários, que normalmente conhecem muito sobre o negócio mas apresentam dificuldades em descrevê-lo. É preciso que o analista de requisitos atue como um investigador e encorajador pois um detalhe que seja omitido pode fazer toda diferença para o produto do software. Requisitos ainda podem ser relacionados entre si, estarem sujeitos à mudanças e quanto maior for o número de requisitos mais difícil será o controle. 4.5 Qualidade dos Requisitos Dentre as qualidades dos requisitos estão: ser correto, completo, consistente, não ambíguo, verificável, ranquiável, modificável, rastreável e compreenssível. Podemos afirmar que um requisito é verificável se existe um processo finito, onde uma pessoa ou ferramenta possa verificar se o requisito foi atendido. Vejamos alguns exemplos: • O sistema deve responder em no máximo 50 msc. • A cor verde deve ser agradável. • O sistema deve estar disponível 24/7. Os requisitos acima não são considerados verificáveis uma vez que: não temos como medir se o sistema respondeu em até 50 msc; a cor 30
  • 31. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 verde deve ser agradável, neste caso o que é agradável? O sistema deve estar disponível 24/7. Neste caso não foi definido o que isto significa. Um requisito é considerado não ambíguo se permitir apenas uma intepretação. Vejamos alguns exemplos: • Aquela velha senhora encontrou o garotinho em seu quarto. • O quarto era da senhora ou do garotinho? • Matou o tigre o casador. • Quem matou quem? • Visitamos o teatro do vilareijo, que foi fundado no século XVIII. • O que foi fundado no século XVIII, o teatro ou o vilareijo? • A polícia cercou o ladrão do banco na rua Santos. • O banco ficava na rua Santos, ou a polícia cercou o ladrão nesta rua? É preciso observamos atentamente a forma como escrevemos, pois a ambiguidade na descrição dos requisitos pode provocar sérios problemas. Podemos escrever algo que seja entendido pelo cliente de uma forma e que seja entendido pela equipe de desenvolvimento de outra forma. 4.6 Disciplina de Requisitos no RUP O processo unificado RUP descreve 9 disciplinas que fazem parte do ciclo de desenvolvimento de software, dentre elas a disciplina de Requisitos. A disciplina de Requisitos do RUP, também conhecida como Workflow de Requisitos descreve o fluxo de atividades relacionadas à requisitos, conforme demonstrado na figura 4.1. O fluxo pode ser lido à partir de duas perspectivas. A primeira descreve as atividades relacionadas à construção de um novo sistema e a 31
  • 32. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 segunda descreve as atividades relacionadas à evolução/manutenção de um sistema existente. Figura 4.1: Fluxo de Atividades de Requisitos do RUP Iniciando nossa análise pela perspectiva de construção de uma novo sistema teremos as atividades: • Análise do problema; • Entendimento das necessidades dos stakeholders; • Definição do sistema; • Gerenciamento do escopo do sistema; • Refinamento da definição do sistema. Partindo da perspectiva da evolução/manuenção de um sistema existente iremos iniciar as atividades pela atividade de entendimento das necessidades dos stakeholders. 32
  • 33. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Paralelo à todas as atividades existe a atividade de gerenciamento de mudanças de requisitos, que podem ocorrer a qualquer momento do projeto. A disciplina de requisitos do RUP define ainda papéis e artefatos do processo. Papéis identificam posições (pessoas) da equipe que são responsáveis pelas atividades a serem desenvolvidas e artefatos identifiam produtos a serem desenvolvidos durante o processo, conforme demonstrado na figura 4.2. Figura 4.2: Papéis e artefatos da disciplina de requisitos do RUP No exemplo acima podemo identificar os papéis de Analista de Sistemas e Especificador de Requisitos e os artefatos Plano de Gerenciamento de Requisitos, Glossário, Stakeholder Requests, dentre outros. 4.7 Principais Artefatos da Disciplina de Requisitos A disciplina de requisitos do RUP apresenta diversos artefatos a serem construídos durante o processo, dentre eles podemos citar: Artefato Documento Visão Características Identificação do problema Identificação dos Atores e Usuários 33
  • 34. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Identificação do Ambiente e Plataforma envolvida Especificação de Requisitos Requisitos Funcionais Especificação Suplementar Requisitos Não Funcionais Especificação de Casos de Uso Casos de Uso mantidos Glossário de Termos Terminologia comum do projeto Stakeholder Requests Necessidades das partes interessadas Tabela 4.1: Principais Artefatos da Disciplina de Requisitos do RUP 5. Análise do Problema 5.1 Entendendo o Problema O workflow de Requisitos do RUP apresenta como primeira atividade a Análise do Problema. Antes mesmo de pensar em requisitos é preciso pensar no problema que existe por trás da necessidade de construir o software. Ninguém ou nenhuma organização irá solicitar a construção de um software se este não tiver o objetivo de resolver um problema específico. É preciso conhecer o domínio do problema para que possamos sugerir soluções que, de fato irão atender as necessidades dos stakeholders e do negócio. O domínio do problema é a casa dos verdadeiros usuários e stakeholders. Aqui o nosso problema é entender o problema a ser resolvido. Compreender os problemas do mundo real, como eles se relacionam com as partes interessadas e propor soluções para atender estes problemas. É preciso obter um melhor entendimento antes do início do desenvolvimento da solução, isto irá nos ajudar a encontrar a solução correta. De acordo com a figura 5.1, o problema pode ser visto como a diferença entre o percebido e o desejado, ou seja, é uma lacuna entre como percebemos as coisas e como as desejamos. 34
  • 35. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Figura 5.1: Representação do Problema A figura demonstra que, normalmente o que percebemos é diferente do que desejamos e esta lacuna é o problema que devemos resolver, ou seja, é preciso desenvolver uma solução que seja capaz de preencher a lacuna existente e, com isto, resolver de fato o problema. O mundo do desenvolvimento de software é dividio em dois espaços distintos: o espaço do problema e o espaço da solução. Ao focarmos nossos esforços no espaço do problema teremos condições de identificar as necessidades dos stakeholders/negócio, também chamadas de Needs. Neste momento não devemos pensar em software, hardware ou em tecnologia da informação em si, mas devemos pensar no negócio, qual é o problema do negócio, o que precisa de solução e não em como será a solução. Desta forma iremos identificar as Needs tanto do negócio quanto dos stakeholders. Após identificarmos as Needs, ou seja, as necessidades do negócio e dos stakeholders, é o momento de focarmos nossos esforços no espaço da solução. Neste momento teremos condições de identificar as características do software, tamabém chamadas de Features. As Features podem ser identificadas como “serviços” que a solução deverá oferecer para atender as Needs (necessidades) do negócio / stakeholders. Assim, para cada Need identificada teremos uma lista de Features que as satisfazem. Ainda no espaço da solução, poderemos identificar os requisitos do software. A relação entre Needs x Features se repete entre Features x Requisitos, ou seja, para cada Feature será necessária uma relação de requisitos que irão atendê-la. A figura 5.2, demonstra a divisão entre espaço do problema e espaço da salução e ainda demonstra a hierarquia entre Needs, Features e Requisitos de Software. 35
  • 36. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Figura 5.2: Relação espaço do problema X espaço da solução Observe a estrutura da tabela 5.1, que demonstra a hierarquia entre Needs, Features e Requisitos: Need NE01 Feature FE001 FE002 FE003 Requisitos RF001 RF002 RF003 RF004 RF005 RF006 RF007 RF008 RF009 RF010 Tabela 5.1: exemplo de hierarquia entre Needs, Features e Requisitos A tabela demonstra que, ao analisarmos o problema identificamos uma Need, denominada de NE01. Para atender a NE01, identificou-se que a solução deverá oferecer três Features (serviços), denominados de FE001, FE002 e FE003. Realizando uma análise ainda mais profunda, afim de identificar os requisitos do software, percebeu-se que para atender a FE001 serão necessários quatro requisitos funcionais: RF001, RF002, RF003 e RF004. Para atender a FE002 serão necessários quatro requisitos: RF005, RF006, RF007 e RF008. E, por fim, para atender à FE003 serão necessários 2 requisitos: RF009 e RF010. Desta forma podemos identificar que, ao 36
  • 37. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 implementarmos todos os requisitos listados a solução irá oferecer todas as Features definidas e por sua vez atenderá à todas as Needs identificadas. Assim, teremos um software que de fato atende à necessidade do negócio/stakeholder. Vejamos um exemplo prático desta estrutura. Começaremos apresentando a descrição de um problema a ser resolvido no Quadro 5.1: Descrição do Problema A escola XYZ não possui um banco de dados com o cadastro de contatos dos professores, isto dificulta a localização de dados cadastrais uma vez que contatos são anotados em agendas de secretárias. Devido ao grande número de professores e disciplinas ofertadas, existe uma dificuldade em identificar qual professor leciona determinada disciplina. Assim há um elevado custo de impressão de holerites de pagamentos que, mensalmente são impressos e entregues a cada professor. Quadro 5.1: Exemplo de descrição do problema Após analisarmos o problema, precisamos identificar qual é o desejo dos stakeholder ou qual são as necessidades do negócio, conforme demonstrado no Quadro 5.2: Desejo dos Stakeholders A escola XYZ gostaria de organizar o gerenciamento e cadastro de seus professores. Gostaria que o registro de contatos dos professores e vínculos com disciplinas pudessem ser organizados e acessados de forma rápida e prática. Entre os desejos dos gestores da escola, encontra-se ainda a possibilidade de extrair relatórios de diversos tipos e permitir que os professores acessem o sistema e realizem consultas de seus holerites de pagamento, que são gerados pelo sistema Folha de Pagamento do RH. Quadro 5.2: Desejo dos Stakeholders 37
  • 38. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Através da análise do problema e do desejo dos stakeholders, poderemos identificar as Needs (necessidades) a serem atendidas, conforme demonstrado na Tabela 5.2: Needs ID Descrição NE001 Gerenciar Cadastro de Professores NE002 Acessar Holerites NE003 Gerenciar Disciplinas Tabela 5.2: Needs identificadas Deveremos então identificar agora quais são as Features, ou seja, quais os serviços necessários para atender cada Need identificada, conforme demonstrado na Tabela 5.3: Needs ID Descrição NE001 Gerenciar ID Feature Cadastro FE001 Manter Professores de Professores FE002 Validar Professores FE003 Gerar Relatório de Professores NE002 Acessar Holerites FE004 Disponibilizar Holerites NE003 Gerenciar Disciplinas FE005 Manter Disciplinas FE006 Vincular Disciplinas Tabela 5.3: Features identificadas Assim identificamos que, para Gerenciar Cadastro de Professores, a solução deverá oferecer os serviços: Manter Professores, Validar Professores e Gerar Relatório de Professores. Para Acessar Holerites, a solução deverá oferecer o serviço: Disponibilizar Holerites e, por fim, para Gerenciar Disciplinas, a solução deverá disponibilizar os serviços Manter Disciplinas e Vincular Disciplinas. Agora poderemos avançar um pouco mais em nossa análise, a ponto de identificar os requisitos do software, necessários para atender cada Feature identificada, conforme exemplo da Tabela 5.4: 38
  • 39. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Needs ID Descrição ID NE001 FE001 Manter Gerenciar Cadastro Professores Feature Professores de ID Requisito RF001 O sistema deverá permitir o cadastro de novos professores RF002 Apenas o usuário do tipo [Administrador] poderá realizar o cadastro e a manutenção de dados dos professores RF003 Ao finalizar o cadastro do professor o sistema deverá enviar um e-mail para o mesmo informando [Senha de uma Acesso Temporária] RF004 O sistema deverá permitir a alteração dos dados dos professores cadastrados RF005 O sistema deverá permitir a exclusão de registros de professores RF006 Somente poderão ser excluídos professores que não possuem alocação de disciplinas RF007 O sistema deverá permitir a pesquisa de professor por meio de informação de parâmetros: [nome] ou [id] Tabela 5.4: Requisitos identificados 39
  • 40. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 5.2 Passos para Análise do Problema Para de fato compreendermos o problema e desenvolvermos uma análise adequada do mesmo, devemos seguir os seguintes passos: • Identificar stakeholders e representantes; • Entender a cauza raíz do problema; • Obter um acordo sobre a definição do problema; • Identificar as restrições; • Definir os limites da solução. Stakeholder é todo indivíduo que é afetado pelo resultado do sistema e que é interessado no projeto. Para identificarmos os stakeholders podemos realizar as seguintes perguntas: • Quem são os usuários do sistema? • Quem é o cliente (aquele que paga) do sistema? • Quem mais será afetado pelas saídas que o sistema irá produzir? • Quem irá avaliar e homologar o sistema quando for implantado? • Existem outros usuários internos ou externos do sistema cujas necessidades precisam ser atendidas? • Quem irá manter o sistema? • Existe alguém mais? 5.3 Identificando as Restrições do Sistema A falta de entendimento do negócio aumenta o risco do projeto. Todo problema possui um componente organização/processo que precisa ser compreendido. É preciso certificar-se que a equipe entendeu o domínio do problema. Outro fator importante a ser compreendido é entender quais são as restrições do sistema. Restrições podem ser de várias naturezas, tais como ambientais, políticas, econômicas, técnicas, sistêmicas, de viabilidade, dentre outras. É importante compreender que, antes de gastar dinheiro desenvolvendo, precisamos identificar todas as restrições impostas à solução. Alguns exemplos de restrições são: 40
  • 41. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Econômicas: restrições financeiras, orçamentárias, problemas de licenciamento. Políticas: existem problemas políticos internos e/ou externos que possam afetar a solução? Técnicas: escolha da tecnologia, plataformas, utilização de pacotes. Sistêmicas: a solução está construída sobre o sistema atual, deverá possuir compatibilidade com o sistema atual? Ambiental: existe restrições ambientais ou legais? Requisitos de segurança são necessários? Existe restrição a algum padrão? Assim podemos concluir que é necessário o levantamento das restrições da solução para que possamos desenvolver o trabalho da melhor maneira possível. 5.4 Identificando os Limites do Sistema Definir os limites do sistema serve como base para a definição e delimitação do escopo do trabalho. Através desta limitação, teremos condições de identificar as fronteiras do sistema, o que fará parte do trabalho e o que não fará parte do trabalho. 5.5 Needs (necessidades) dos Stakeholders e do Negócio A definição das necessidades dos stakeholders e do negócio são, sem dúvidas, o passo mais crítico do esforço realizado pelo analista de requisitos. Esta tarefa identifica o problema para o qual o analista de requisitos tenta encontrar uma solução. De acordo com o BABOK (2012) “...uma questão encontrada na organização, como uma reclamação de um cliente, a perda de receita ou uma nova oportunidade de mercado, geralmente desencadeia a avaliação de uma necessidade de negócio.” Ou seja, à partir da análise do problema teremos condições de identificar quais são as necessidades dos stakeholders e do problema. Necessidades podem ser identificadas de diferentes formas: 41
  • 42. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • De cima para baixo: a necessidade de atingir uma meta estratégica. • De baixo para cima: um problema com a situação atual de um processo, função ou sistema. • Da média gerência: um gerente precisa de informação adicional para tomar decisões. • De direcionadores externos: direcionados por uma demanda de cliente ou pela competição no mercado. A figura 5.2 demonstra que, as Needs se localizam no topo do pirâmede. A partir da sua descrição teremos condições de identificar as features e requisitos, que são os itens abaixo. Needs identificam o que é necessário (qual a necessidade) para que o problema identificado seja resolvido. 5.6 Features (características) do Software De acordo com a figura 5.2, as Features se localizam no segundo nível da pirâmide. Elas são declarações totalmente derivadas das Needs, que são as necessidades identificadas. A declaração das Features deve buscar identificar serviços necessários que a solução deverá oferecer afim de atender as necessidades identificadas. Dentre algumas definições para as Features, podemos identificar: um serviço que o sistema fornece para atender uma ou mais necessidades dos stakeholders. Vejamos alguns exemplos: No exemplo apresentado no quadro 5.1, uma das Needs (necessidades) identificadas era de Gerenciar o Cadastro de Professores, desta forma foram identificados os serviços necessários para que fosse possível realizar o gerencimanento de professores, desta forma foram elencadas as features: Manter Professores, Validar Professores e Gerenciar Relatório de Professores. Ao analisarmos o exemplo, podemos perceber que as features são declaração de alto nível, uma vez que não possuem detalhes necessários para a implementação. Apenas identificam os serviços à serem oferecidos. Para que possamos atender a need Gerenciar o Cadastro de Professores a 42
  • 43. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 solução deverá oferecer os serviços de manutenção de professores, ou seja um CRUD (cadastrar, consultar, atualizar e deletar), deverá realizar as devidas validações de dados e por fim realizar a geração de relatórios. As Features estão na segunda posição da pirâmide, ou seja, entre as Needs e os requisitos. As Features são derivadas das Needs e os requisitos são derivados das Features. 5.7 Requisitos do Software Após identificarmos as Features da solução, temos condições de identificar os requisitos. Os requisitos são derivados das Features. Para cada Feature identificada termos um ou mais requisitos do software, que irão tratar em maiores detalhes como as Features serão atendidas. Da mesma forma que cada Features deverá atender uma ou mais Need, cada requisito deverá atender uma ou mais Feature. Analisando ainda o exemplo anterior, identificamos a Feature Manter Professores. Para atender esta Feature identificamos os requisitos: • O sistema deverá permitir o cadastro de novos professores. • Apenas o usuário do tipo [Administrador] poderá realizar o cadastro e a manutenção de dados dos professores. • O sistema deverá permitir a alteração dos dados dos professores cadastrados, etc... 5.8 Capturar Vocabulário Comum Uma tarefa de extrema importância durante o ciclo de desenvolvimento do software é a capturação de um vocabulário comum (Glossário de Termos). Muitas vezes nos envolvemos em projetos de desenvolvimento de software para atender as mais deversas áreas, tais como software contábeis, jurídicos, de gestão de produção, ERPs, etc... Cada software atende uma área específica e cada área possui o seu vocabulario, como termos técnicos, jargões, etc. Muitas vezes ao realizarmos o levantamento de requisitos nos deparamos com estes termos, por isto, é de 43
  • 44. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 extrema importância que durante todo o processo de desenvolvimento estes termos sejam identificados e agrupados no documento chamado Glossário, onde qualquer membro do time poderá consultar o significado de cada termo relacionado ao negócio. 6. Entendendo a Necessidade do Stakeholder 6.1 Capturando Necessidades A segunda atividade do workflow de Requisitos do RUP é Entender a Necessidade do Stakeholder. Nesta atividade o analista de requisitos deverá coletar e extrair informações das partes interessadas no projeto. A partir deste levantamento será possível construir uma lista de desejos que irá nortear todo o processo de desenvolvimento. Ao longo do projeto, os pedidos das partes interessadas devem continuar sendo analisados. 6.2 Atividades e Artefatos A necessidade dos Stakeholders servirá de base para a construção de diversos artefatos pertencentes ao workflow de Requisitos, dentre eles Stakeholder Request, Documento Visão, Modelo de Casos de Uso e Especificação Suplementar. 6.3 Problemas a Serem Encontrados Durante o processo de levantamento de necessidades (Needs), features e requisitos, o analista de requisitos pode se deparar com diversos problemas, dentre eles podemos citar: normalmente os stakeholders possuem uma pré-concepção da solução, isto muitas vezes pode atrabalhar o levantamento de necessidades, pois corremos o risco dele achar que precisa de algo quando, na verdade, ele precisa de outra coisa. Podemos nos deparmos também com situaçõe onde os stakeholders sabem o que querem, porém não sabem expressar exatamente o que querem. Sempre que realizar 44
  • 45. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 o levantamento o analista de requisitos deve procurar enteder bem o problema para que possa ser possível decidir se, o que o stakeholder solicitou irá, de fato resolvê-lo. Outro problema comumente encontrado durante o levantamento de requisitos é o fato de o analista achar que sabe mais sobre a solução do que o próprio stakeholder. Muitas vezes, com o acúmulo de experiência o analista pode se achar capacitado a decidir qual a melhor solução, tendo realizado pouca investigação do problema. Esta atitude pode prejudicar todo o processo de desenvolvimento e induzir o time de desenvolvimento a desenvolver uma solução não adequada para o problema. O trabalho de análise de requisitos é uma trabalho onde não pode haver pressa, é preciso ter paciência e ser investigativo para tentar absorver o maior número de detalhes possível. 6.4 Artefato Stakeholder Request (Pedidos dos Envolvidos) Pedidos dos stakeholders são obtidos e reunidos ativamente a partir de origens existentes para obter uma "lista de desejos" do que os diferentes stakeholders do projeto (clientes, usuários, patrocinadores do produto) esperam ou desejam que o sistema inclua, juntamente com informações sobre como cada pedido foi considerado pelo projeto. A finalidade dessa tarefa é: • Entender quem são os stakeholders do projeto. • Coletar pedidos de quais necessidades o sistema deve preencher. • Priorizar pedidos dos envolvidos. Este artefato contém qualquer tipo de pedido dos envolvidos (cliente, usuário, pessoal de marketing, etc.) em relação ao sistema que será desenvolvido. Ele também pode conter referências a qualquer tipo de fonte externa com a qual o sistema deve estar de acordo. A finalidade deste artefato é capturar todos os pedidos feitos em relação ao projeto e o modo como eles foram abordados. Embora o analista de requisitos seja responsável por esse artefato, várias pessoas contribuirão 45
  • 46. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 para ele: pessoal de marketing, usuários, clientes - qualquer pessoa considerada como um envolvido no resultado do projeto. Essas informações podem ser coletadas em um documento ou ferramenta automatizada e os pedidos apropriados devem ser controlados e relatados seguindo um processo de Gerenciamento de Controle de Mudanças. Exemplos de origens dos Pedidos dos Envolvidos: • Resultados das entrevistas dos envolvidos • Resultados das sessões e dos workshops de identificação de requisitos • CR (Controle de Mudanças) • Relatório de trabalho • Pedido de proposta • Declaração da missão • Declaração do problema • Regras do negócio • Leis e regulamentações • Sistemas legados • Modelo de Negócios O quadro 6.1 demonstra o formato do documento Stakeholder Request / Pedidos dos Envolvidos: 1. Introdução 1.1 Objetivo 1.2 Escopo 1.3 Definições, Acrônomos e Abreviações 1.4 Referências 1.5 Visão Geral 2. Estabelecer Perfil do Investidor ou do Usuário 3. Avaliando o Problema 4. Entendendo o Ambiente do Usuário 5. Recapitulação para Entendimento 6. Entradas do Analista no Problema do Invesidor (validar ou invalidar premissar) 46
  • 47. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 7. Avaliando sua solução (se aplicável) 8. Avaliando a oportunidade 9. Avaliando a confiabilidade, o desempenho e as necessidades de suporte 9.1 Outros requisitos 10. Wrap-UP 11. Resumo do Analista Quadro 6.1: Conteúdo do Documento Stakeholder Request 6.5 Elicitação de Requisitos A elicitação de requisitos é tarefa chave do papél de analista de requisitos. Elicitar requisitos é fundamental para compreender o problema, entender as necessidades do negócio / stakeholder, capturar as features do sistema e os requisitos funcionais e não funcionais. O analista de requisitos deve preparar a elicitação de forma a garantir que todos os recursos necessários estejam organizados e agendados para a condução do trabalho. Algumas das principais técnicas utilizadas para elicitação de requisitos são: • Brainstorming • Análise de Documentos • Workshop de Requisitos • Entrevistas • Observação 6.5.1 Brainstorming Uma das formas mais eficientes de elicitar requisitos, o brainstorming fomenta o pensamento criativo sobre algum problema. O objetivo é produzir novas ideias para análise futura e ajuda na respostas de questões como: • Quais opções estão disponíveis para atuar sobre a questão em mãos? • Quais fatores estão impedindo o grupo de avançar com uma abordagem ou opção? 47
  • 48. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • O que poderia estar causando um atraso na atividade “A”? • O que o grupo pode fazer para resolver o problema “B”? De acordo com o BABOK 2.0 “O brainstorming funciona através do foco em um topico ou problema e, então, levantando varias soluções possíveis para ele. Esta tecnica é melhor aplicada em grupo porque se alimenta da experiência e criatividade de todos os seus membros.” Caso não exista um grupo, uma pessoa poderá realizá-lo sozinha com o intúito de desencadear suas próprias ideias. Desde que seja facilitado de forma correta, o brainstorming pode ser divertido, envolvente e produtivo. 6.5.1.1 Vantagens do Brainstorming De acordo com o BABOK 2.0, as vantagens do brainstorming são: • Habilidade de elicitar muitas ideias em um curto período de tempo. • Ambiente livre de julgamentos permite pensamento criativo. • Pode ser útil durante um workshop para reduzir a tensão entre os participantes. 6.5.1.2 Desvantagens do Brainstorming De acordo com o BABOK 2.0, as desvantagens do brainstorming são: • Dependente da criatividade ou disposição dos participantes. Politicas organizacionais ou interpessoais também podem limitar a participação. • Participantes devem concordar em evitar debater as ideias surgidas durante o brainstorming. 6.5.2 Análise de Documentos A anáise de documentos visa elicitar requisitos através do estudo de soluções existentes e outras informações que possam ser relevantes para o projeto. 48
  • 49. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 A analise de documentos pode incluir analise de planos de negocio, estudos de mercado, contratos, requisições declarações de de trabalho, propostas, memorandos, orientações existentes, procedimentos, guias de treinamentos, literatura a respeito de produtos concorrentes, comparativas publicadas reportes problemas, de revisões de produtos, registros de sugestões de clientes, especificações de sistemas existentes, entre outros. A identificação e consulta a todas as fontes de requisitos resultarão em uma cobertura aperfeiçoada dos requisitos, assumindo-se que a documentação esteja atualizada. (BABOK 2.0) A análise de documentos se aplica quando o objetivo for entender detalhes das soluções existentes, quando especialistas da área da solução existe não se encontram mais na empresa ou não estam disponíveis para apoiar o processo de elicitação de requisitos. 6.5.2.1 Vantagens da Análise de Documentos De acordo com o BABOK 2.0, as vantagens da Análise de Documentos são: • Nao iniciar a partir de uma folha em branco. • Utilizar materiais existentes para descobrir e/ou confirmar requisitos. • Um meio de verificar os requisitos de outras tecnicas de elicitação como entrevistas, observação passiva, pesquisas ou grupos focais. 49
  • 50. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 6.5.2.2 Desvantagens da Análise de Documentos De acordo com o BABOK 2.0, as desvantagens da Análise de Documentos são: • Limitado a perspectiva “as-is” (como e). • A documentação existente pode nao estar atualizada ou não ser mais valida. • Pode consumir muito tempo e transformar-se em um processo tedioso a localização de informações relevantes. 6.5.3 Workshop de Requisitos Um workshop de requisitos é uma forma organizada de elicitar requisitos. Um workshop pode ser utilizado para investigar, descobrir, definir, priorizar e atingir o fechamento dos requisitos do sistema alvo. De acordo com BABOK 2.0 “Workshops bem executados são considerados a forma mais efetiva de entregar prontamente os requisitos de alta qualidade. Eles podem promover confiança, compreensão mútua e forte comunicação entre as partes interessadas do projeto e time do projeto, e produzem entregas que estruturam e orientam a analise futura.” Um workshop de requisitos é um evento altamente produtivo participação das e focado, principais com a partes interessadas e especialistas no assunto, cuidadosamente período curto selecionados, e intenso de para um trabalho (tipicamente um ou alguns dias). O workshop é facilitado por um membro da equipe, ou de forma ideal, por um facilitador experiente e neutro. Um escriba (também conhecido como registrador) documenta os requisitos elicitados como também quaisquer questões importantes. (BABOK 2.0) 50
  • 51. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Durante o Workshop há a necessidade de atuação de um facilitador, entende-se que o analista de requisitos deverá desempenhar este papél. Em situações onde o analista de requisitos é um especialista no assunto, ele pode servir como um dos participantes do workshop. Contudo, isso deve ser feito com cautela, uma vez que pode confundir os demais em relação ao papel do analista de requisitos. 6.5.3.1 Vantagens do Workshop de Requisitos De acordo com o BABOK 2.0, as vantagens do Workshop são: • Um workshop de requisitos pode ser um meio de elicitar requisitos detalhados em um período de tempo relativamente curto. • Um workshop de requisitos fornece meios para as partes interessadas colaborarem, tomarem decisões e atingirem a compreensão mútua dos requisitos. • O custo de um workshop de requisitos e, muitas vezes, inferior ao custo da condução de várias entrevistas. Um workshop de requisitos permite que os participantes trabalhem em conjunto para atingir um consenso. Esta pode ser uma abordagem mais barata e rapida do que a execução de várias entrevistas de requisitos, uma vez que entrevistas podem levar a requisitos conflitantes e o esforço necessário para solucionar esses conflitos junto a todos os entrevistados pode ser muito custoso. • O feedback é imediato. A interpretação do facilitador dos requisitos é fornecida imediatamente para as partes interessadas e validada. 6.5.3.2 Desvantagens do Workshop de Requisitos De acordo com o BABOK 2.0, as desvantagens do Workshop são: • A disponibilidade das partes interessadas pode tornar dificil a programação do workshop de requisitos. 51
  • 52. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • O sucesso do workshop de requisitos é altamente dependente da habilidade do facilitador e do conhecimento dos participantes. • Workshops de requisitos que envolvem muitos participantes podem tornar o processo lento. Por outro lado, coletar informações de poucos participantes pode levar a ignorar requisitos que são importantes para usuarios, ou a especificar requisitos que nao representam as necessidades da maioria dos usuarios. 6.5.4 Entrevistas Uma entrevista é uma abordagem sistematica desenhada para elicitar informações junto a uma pessoa ou a um grupo de pessoas de maneira formal ou informal através de uma conversa com um entrevistado, na qual são feitas perguntas relevantes e as respostas são documentadas. Em uma entrevista, o entrevistador faz perguntas informalmente a uma parte interessada para obter respostas que irão ser usadas para criar requisitos formais. Entrevistas um a um são mais comuns. Em uma entrevista em grupo (com mais de um entrevistado presente) o entrevistador deve se preocupar em elicitar respostas de todos os presentes. Para o propósito de elicitar requisitos, as entrevistas sao de dois tipos básicos: • Entrevista Estruturada: onde o entrevistador possui um conjunto pre-definido de questões e procura respostas para elas. • Entrevista Não-Estruturada: onde, sem nenhuma questão pre-definida, o entrevistador e o entrevistado discutem abertamente topicos de interesse . Entrevistas bem-sucedidas dependem de varios fatores incluindo, mas não limitados a: • Nível de compreensão do domínio pelo entrevistador. • Experiência do entrevistador na condução das entrevistas. 52
  • 53. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • Habilidade do entrevistador em documentar as discussões. • Prontidão do entrevistado para fornecer informacoes relevantes. • Grau de clareza na mente do entrevistado em relação ao que o negócio requer do sistema em discussão. • Empatia (rapport) do entrevistador com o entrevistado. 6.5.4.1 Vantagens da Entrevista De acordo com o BABOK 2.0, as vantagens do Entrevsta são: Encoraja a participação e estabelece empatia (rapport) junto a parte interessada. Tecnica simples e direta que pode ser usada em diferentes situações. Permite que o entrevistador e o participante tenham discussões e explicações amplas sobre perguntas e respostas. Permite a observação de aspectos nao-verbais. O entrevistador pode fazer perguntas de seguimento ou de sondagem para confirmar a sua compreensão. Mantém o foco através do uso de objetivos claros para a entrevista, com os quais todos os participantes concordaram e que podem ser alcançados dentro do tempo alocado. Permite aos entrevistados expressar opiniões de forma privada que relutariam em expressar de forma pública. 6.5.4.2 Desvantagens da Entrevista De acordo com o BABOK 2.0, as desvantagens do Entrevsta são: Entrevistas nao sao o meio ideal de se alcançar consenso entre um grupo de partes interessadas. Requer dedicação e envolvimento consideráveis por parte dos participantes. 53
  • 54. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 A profundidade das perguntas subsequentes depende do conhecimento do entrevistador em relação ao dominio do negócio. A transcrição e analise dos dados da entrevista podem ser complexas e caras. Com base no nivel de clareza da entrevista, a documentação resultante pode estar sujeita à interpretação do entrevistador. Existe um risco de influenciar de forma não intencional o entrevistado. 6.5.5 Observação A observação é uma forma de elicitar requisitos através da condução de uma avaliação do ambiente de trabalho da parte interessada. Esta tecnica é apropriada para documentar detalhes sobre processos atuais ou quando o projeto se destina a melhorar ou alterar um processo atual. A observação baseia-se no estudo das pessoas na execução das suas funções e e as vezes chamada de “siga o mestre” (“ job shadowing” ou “ following people around”). Por exemplo, algumas pessoas estão tão habituadas com sua rotina de trabalho que elas tem dificuldade de explicar o que fazem ou por quê. O observador pode precisar assistí-los executando o seu trabalho para compreender o fluxo de trabalho. Em certos projetos, é importante compreender os processos atuais para melhor avaliar as modificações em processos que podem ser necessárias. Há duas abordagens basicas da tecnica de observação: Passiva/invisível: Nesta abordagem, o observador acompanha o usuario trabalhando na rotina do negócio e não faz perguntas. O observador registra o que é observado, mas permanece fora do caminho. O observador aguarda até que o processo todo tenha sido completado antes de fazer qualquer pergunta. O observador deve examinar o processo de negócios várias vezes para garantir que ele compreende 54
  • 55. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 como o processo funciona hoje e por que funciona desse jeito. Ativa/visível: Nessa abordagem, enquanto o observador analisa o processo atual e toma notas, ele pode dialogar com o usuario. Quando o observador tem perguntas como, a razão pela qual algo esta sendo feito de tal maneira, ele faz a pergunta imediatamente, mesmo se ela quebre a rotina do usuario. Variações da tecnica de observação: Em alguns casos, o observador pode participar do trabalho real para obter uma experiência prática de como o processo de negócio funciona hoje. Este procedimento seria limitado a uma atividade que uma pessoa não especializada possa executar e cujos resultados não afetem negativamente o negócio. O observador torna-se um aprendiz temporário. O observador assiste a demonstração de como um processo e/ou tarefa específicos são executados. 6.5.5.1 Vantagens da Observação De acordo com o BABOK 2.0, as vantagens da Observação são: Fornece uma visão pratica e realista do negócio através da experiência “mão na massa” de como os processos de negócio funcionam hoje. Elicita detalhes da comunicação informal e a forma como as pessoas realmente trabalham com o sistema, o que pode não estar documentado em outros lugares. 55
  • 56. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 6.5.5.2 Desvantagens da Observação De acordo com o BABOK 2.0, as desvantagens da Observação são: • Possível apenas para processos existentes. • Pode consumir muito tempo. • Pode atrapalhar a pessoa sendo observada. • Situações incomuns e exceções que ocorrem com pouca frequência podem não ocorrer durante a observação. • Pode não funcionar bem se o processo atual envolver um alto nivel de atividade intelectual ou outro trabalho que não seja de fácil observação. 6.5.6 Outras Técnicas Importantes Várias outras técnicas podem ser utilizadas para a elicitação de requisitos, dentre elas destacam-se: • Grupos Focais • Análise de Interfaces • Prototipagem • Pesquisa / Questionário • JAD 6.5.7 Obstáculos da Elicitação de Requisitos Ao entregarmos o software, é comum observarmos 2 tipos de reações: • “UAU, que legal! Podemos realmente fazer isto, fantástico!” • “Sim, mas, huuuummmmmmm, como eu vejo isso? Para que serve esse...? Não seria melhor se...? O que acontece se...?” A chamada “Síndrome do Sim, Mas”, faz parte do cotidiano humano, podemos reduzí-la se buscarmos atacar o “MAS” desde o início. Investigue tudo no início. 56
  • 57. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Grande parte dos obstáculos enfrentados durante a elicitação de requisitos é devido ao fato de que usuários e desenvolvedores normalmente possuem mundos diferentes, falam linguas diferentes, possuem experiências, objetivos e motivações diferentes, portanto é de fundamental importância que o analisata de requisitos saiba se comunicar com estes “usuários de outras tribos”. 7. Atividades de Requisitos 7.1 Especificação de Requisitos A especificação de requisitos é o processo que permite analisar e documentar os desejos das partes interessadas no projeto usando uma combinação de declarações textuais, matrizes, diagramas e modelos formais. Segundo o BABOK 2.0 “especificações e modelos são criados para analisar o funcionamento de uma organização e para prover insights sobre oportunidades de melhoria.” Podem ainda apoiar outros objetivos, incluindo o desenvolvimento e implementação de soluções, facilitação da comunicação entre as partes interessadas, apoio à atividades de treinamento e gerenciamento do conhecimento e garantia do atendimento à contratos e regulamentos. As especificidades desta tarefa dependem das tecnicas usadas para especificar e modelar requisitos. 7.2 Requisitos Funcionais Requisitos Funcionais descrevem as funcionalidades que o software deverá oferecer, ou seja, o comportamento e a informação que a solução irá gerenciar. Descrevem capacidades que o sistema será capaz de executar em termos de comportamentos e operações – ações ou respostas especificas de aplicativos de tecnologia da informação. 57
  • 58. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 7.2.1 Exemplos de Requisitos Funcionais • [RF001] O sistema deverá permitir o registro de um novo produto. • [RF002] O sistema deverá permitir a alteração dos dados de um produto cadastrado. • [RF003] O sistema deverá gerar um relatório de totalização de vendas por período. 7.3 Requisitos Não Funcionais Os Requisitos Não Funcionais capturam condições que não se relacionam diretamente ao comportamento ou funcionalidade da solução, mas descrevem condições ambientais sob as quais a solução deve permanecer efetiva, ou qualidades que os sistemas precisam possuir. De acordo com o BABOK 2.0 “também são conhecidos como requisitos de qualidade ou suplementares. Podem incluir requisitos relacionados à capacidade, velocidade, seguranca, disponibilidade, arquitetura da informação e apresentação da interface com o usuario.” 7.3.1 Exemplos de Requisitos Não Funcionais • Os relatórios devem ter a opção de visualização em PDF, HTML e XLS. • O software deve ser multiplataforma. 7.4 Planejar o Processo de Gerenciamento de Requisitos Determina como serão os processos de aprovação dos requisitos e gerenciamento das mudanças de escopo da solução ou dos requisitos. Determina o processo para mudanças nos requisitos, quais stakeholders precisam aprovar as mudanças, quem será envolvido nas mudanças e quem não será. Avalia a necessidade de rastreabilidade e quais atributos de requisitos serão capturados. 58
  • 59. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 7.4.1 Repositório Um método de armazenamento de requisitos, incluindo aqueles em desenvolvimento, aqueles sob revisão e os requisitos aprovados. Repositórios podem incluir quadros brancos, documentos de editores de textos, diagramas e modelos, wikis, ferramentas e aplicações de gerenciamento de requisitos, ou qualquer outra forma de registro de informação que permita que os requisitos possuam uma unica origem e estejam disponiveis para todas as partes interessadas relevantes, enquanto forem necessários. Segudo o Babok 2.0 “todos os requisitos aprovados devem ser encontrados em um repositório (em oposição ao uso de ferramentas como email, que podem não alcançar todas as partes interessadas relevantes e podem não ser conservadas) e as partes interessadas precisam ser capazes de localizar os requisitos naquele repositório.” 7.4.2 Rastreabilidade Determina como rastrear os requisitos, quais os poenciais impactos de risco em uma compreensão dos custos e beneficios envolvidos. Adiciona uma atenção considerável ao trabalho de analise de requisitos e deve ser efetuado correta e consistentemente para possuir valor. 7.4.3 Selecionar Atributos dos Requisitos (extraído do BABOK 2.0) Proveem informação a respeito dos requisitos, como a fonte do requisito, a importância do requisito e outros metadados. Atributos auxiliam no gerenciamento contínuo dos requisitos ao longo do ciclo de vida do projeto. Eles precisam ser planejados e determinados junto com os requisitos, mas nao constituem em si parte da definição da solução. Permitem que a equipe de requisitos associe informações a requisitos individuais ou grupos de requisitos relacionados e facilitam o processo de analise de requisitos, expressando informações como quais requisitos devem adicionar risco ao projeto ou requerem analise adicional. A informação documentada pelos atributos auxilia a equipe a fazer trocas 59
  • 60. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 eficazes e eficientes entre requisitos, identificar partes interessadas afetadas por potenciais mudanças e compreender o impacto de uma mudança proposta. Alguns atributos de requisitos frequentemente utilizados incluem: • Referencia absoluta. É um identificador numérico (preferencialmente) ou textual exclusivo. A referência não é alterada ou reutilizada caso o requisito seja movido, modificado ou excluído. • Autor do requisito. Se o requisito for considerado ambiguo, o autor pode ser consultado para esclarecimentos. • Complexidade. Indica quão difícil será a implementação dos requisitos. Ela e frequentemente indicada através de escalas qualitativas com base em número de interfaces, complexidade de processos essenciais, ou a quantidade e natureza dos recursos requeridos. • Propriedade. Indica o individuo ou grupo que precisa do requisito, ou que será o dono do negócio após o projeto ser liberado no ambiente alvo. • Prioridade. Indica quais requisitos precisam ser implementados primeiro. Veja abaixo discussão a respeito da priorização e gerenciamento de requisitos. • Riscos. Associados ao atendimento, ou nao, dos requisitos. • Fonte do requisito. Todo requisito deve ser originado de uma fonte que possui autoridade para definir este conjunto particular de requisitos. A fonte deve ser consultada se o requisito for alterado, ou se mais informação referente ao requisito, ou a necessidade que direcionou o requisito, tiver que ser obtida. • Estabilidade. É usada para indicar o quão maduro o requisito é. Ela e usada para determinar se o requisito é firme o suficiente para que se possa trabalhar sobre ele. Note que a presença de grande número de requisitos instáveis no núcleo do projeto pode indicar um risco significativo a sua 60
  • 61. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 continuação. • Estado do requisito, indicando se ele esta proposto, aceito, verificado, adiado, cancelado ou implementado. • Urgência indica quão cedo o requisito é necessário. Só é especificada de forma separada da prioridade quando existe um prazo limite para a implementação. • Atributos adicionais podem incluir informacoes como custo, alocação de recursos, número de revisão, rastreado da origem e rastreado ao destino. 7.4.4 Processo de Priorização dos Requisitos (extraído do BABOK) Nem todos os requisitos entregam o mesmo valor para as partes interessadas. A priorização foca esforço na determinação de quais requisitos devem ser investigados antes, com base no risco associado a eles, o custo para entregá-los, os beneficios que eles irão produzir, entre outros fatores. Linhas do tempo, dependências, restrições de recursos e outros fatores influenciam em como os requisitos são priorizados. Planejar o processo de priorização dos requisitos auxilia a garantir que as partes interessadas determinam e compreendem como os requisitos serão priorizados ao longo e ao final do esforço da analise de requisitos. Formalidade. A formalidade e o rigor da priorização dos requisitos são determinados parcialmente pela metodologia escolhida e pelas caracteristicas do projeto em si. Estabelecimento do Processo e Tecnica. O processo para planejar como a priorização dos requisitos acontecerá precisa incluir qual(is) tecnica(s) de priorização sera(ao) usada(s). Planejar a Participação. O analista de requisitos, junto ao gerente do projeto e ao patrocinador devem trabalhar em conjunto para determinar os participantes necessários para o processo de priorização. Quem convidar e quem é responsavel pelos convites dependem das normas organizacionais e melhores práticas. Uma vez que patrocinadores são, em ultima instância, responsabilizados pela efetividade 61
  • 62. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 da solução e pelas grandes decisões do projeto, eles precisam ser convidados à participar da discussão, mesmo quando eles delegam a participação para especialistas no assunto. Outra principal parte interessada é o gerente do projeto, cujo plano é dependente de quais requisitos serão liberados e quando. Os convites dependem das metodologias, normas organizacionais e engajamento do patrocinador. Quando existirem muitos fatores limitantes, convide participantes de acordo com eles. 7.4.5 Gerenciamento de Mudanças (extraído do BABOK) Determinar o processo de requisição de mudanças. O processo pode, mas não é obrigado a estabelecer níveis de autorização para a aprovação de mudanças. Por exemplo, pode ser decidido que se uma mudança, quando estimada, tomar menos do que uma determinada quantidade de tempo ou dinheiro, o requisitante e o gerente do projeto poderão aprová-la. Caso o limite seja ultrapassado a aprovação deverá vir do patrocinador. Determinar quem irá autorizar as mudanças. A atividade de planejamento precisa incluir a designação de quem poderá aprovar mudanças, uma vez aprovados os requisitos. Métodos orientados ao planejamento geralmente possuem um comitê formal de controle de mudanças (CCM), ou Autoridade de Mudança, que considera a mudança requisitada e provê um julgamento inicial dos méritos dessa requisição. O comitê de controle de mudanças pode ser formado por diferentes quantidades de pessoas oriundas de diferentes posições. Ele pode ou não incluir o patrocinador, o gerente do projeto, o analista de requisitos, o especialista no assunto ou outros grupos. Metodos orientados à mudança tendem a permitir que a equipe do projeto ou um único proprietário do produto tenha controle direto sobre as mudanças. Analise do Impacto. Especificar quem irá executar a analise dos impactos, como processos de negócio, requisitos de informação, interfaces de sistemas e hardware, outros produtos de software, outros requisitos, estrategias e planos de testes, para mencionar alguns. 62
  • 63. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Planejar a redação da requisicao. É importante estabelecer no início das atividades de analise de requisitos a expectativa de que, apesar da documentação necessária para requisitar mudanças depender da metodologia e do projeto, a redação do requisicao deve ser clara. A mudança requisitada deve ser expressa em termos nao ambiguos. Ainda assim será necessario discutir a natureza da requisição com o requisitante e outras partes interessadas. 7.4.6 Gerenciar o Escopo e os Requisitos da Solução (extraído do BABOK) Obter e manter consenso entre as principais partes interessadas acerca do escopo genérico da solução e os requisitos que serão implementados. Esta tarefa envolve assegurar a aprovação dos requisitos pelas partes interessadas com autoridade competente para tal e o gerenciamento de questões que surjam durante a elicitação e a analise. A aprovação dos requisitos pode ser solicitada ao término de uma fase de projeto ou em varios outros pontos intermediarios dentro do processo de analise de requisitos. Após aprovação dos requisitos, uma linha de base pode ser gerada. Qualquer alteração nos requisitos após a geração da linha de base, se alterações forem permitidas, envolve o uso de um processo de controle de mudancas e subsequente aprovação. A medida que requisitos são refinados ou modificados como resultado de novas informações, as mudanças também são mapeadas. O escopo da solução é necessário como base para o gerenciamento de requisitos e é usado para determinar se um requisito proposto apoia as metas e os objetivos do negócio. Se a necessidade do negócio mudar durante o ciclo de vida de uma iniciativa, o escopo da solução também deverá ser modificado. Mudanças no escopo da solução podem também levar à mudanças em requisitos previamente aprovados, que podem nao apoiar o escopo revisado. Abordagens orientadas a mudança tipicamente não fazem uso de um processo formal de controle de mudanças, na medida em que os 63
  • 64. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 requisitos são priorizados e selecionados para implantação no inicio de cada iteração e nenhuma mudança nos requisitos ocorre durante uma iteração. 7.4.7 Gerenciar Conflitos (extraído do BABOK) A medida que requisitos são desenvolvidos e revisados, frequentemente surgem conflitos. Um conflito pode vir de partes interessadas de diferentes areas vendo os mesmos requisitos de diferentes perspectivas. Também podem ser fruto de prioridades conflitantes. Requisitos inconsistentes não podem ser resolvidos por uma única solução, portanto, qualquer inconsistência deve ser resolvida. Para resolver a questão, facilite a comunicação entre as partes interessadas que estão em conflito por causa do requisito. Conflitos podem ser resolvidos em encontros formais entre as partes interessadas afetadas, através de pesquisa, resolução por um terceiro, ou ainda por outros métodos apropriados. Conflitos que afetem os requisitos precisam ser resolvidos antes que a aprovação formal seja dada àqueles requisitos. 7.5 Apresentando Requisitos para Revisão (extraído do BABOK) Determine como os requisitos serão apresentados para as várias partes interessadas e se as apresentações serão formais ou informais. Uma apresentação formal pode ser uma especificação dos requisitos do sistema por escrito ou uma revisão estruturada com varios níveis de partes interessadas, incluindo sumarios executivos, assim como um modelo estruturado, contendo todos os diagramas associados, texto de apoio, atributos detalhados e informação de revisão. Um requisito pode ser apresentado informalmente em um e-mail, uma nota, ou verbalmente. Avalie os requisitos, o público e os ativos de processos organizacionais para determinar o nivel de formalidade apropriado para a comunicação da analise de requisitos. Geralmente, quanto mais formal a comunicação, mais tempo será necessário para se preparar para as reuniões, revisões, para apresentações, preparações ou pacotes de requisitos, etc. Comunicações menos formais podem resultar em falta de 64
  • 65. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 informações relevantes às partes interessadas, ou em uma maior ambiguidade nos requisitos. Ao apresentar requisitos para revisão e aprovação é necessário que haja formalidade o suficiente para apoiar a metodologia e garantir que as partes interessadas irão revê-los, entendê-los e aprová-los. 7.5.1 Aprovação (extraído do BABOK) Garanta que a(s) parte(s) interessada(s) responsável(eis) por aprovar os requisitos os compreendem e os aceitam. A aprovação de partes interessadas pode ser necessária para o resultado de outras tarefas da analise de requisitos, incluindo alocação de requisitos, resoluções de problemas propostos e outras decisões. A aprovação pode ser obtida por uma parcela das partes interessadas, individualmente, ou em grupo. Um registro da decisão pode ser mantido. Um registro da decisão pode incluir a decisão tomada (incluir ou não o requisito, ou modificar o escopo), a razão para esta decisão e as partes envolvidas. 7.6 Comunicar os Requisitos (extraído do BABOK) Comunicar requisitos é fundamental para levar as partes interessadas a uma compreensão comum dos requisitos. Comunicar requisitos inclui conversas, anotações, documentos, apresentações e discussões. Comunicação concisa, apropriada e efetiva requer que o analista de requisitos possua um conjunto significativo de habilidades tanto interpessoais (comunicação), quanto tecnicas (ex.: requisitos). 7.7 Regras de Negócio O RUP define Regras de Negócio como declarações sobre políticas ou condições que devem ser satisfeitas. A declaração da regra de negócio não afirma que deve ser satisfeita pelo sistema pois regra de negócio 65
  • 66. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 é uma restrição imposta pelo negócio, que regulamento o comportamento de um procedimento operacional do negócio. Regras de Negócio podem ser originárias de leis, portarias e/ou normas reguladoras. As RNs (Regras de Negócios) possuem vida totalmente idenpendente do sistema, pois uma vez que não exista sistema informatizado, as RNs devem prevalecer para que sejam atendidas as exisgências do negócio, por exemplo: Imagine uma pequena empresa totalmente desprovida de qualquer computador ou sistema. A administração definiu que a venda à prazo só poderá ser feita para clientes adimplentes. Neste caso, a RN pertence apenas ao domínio do negócio e não ao domínio do sistema, mas poderá ser automatizada através de um sistema de informação, neste caso, será necessário um requisito funcional para atender a regra. Podemos observar ainda que, normalmente uma RN possuirá um “SE...Então...Else”. 7.7.1 Recomendações para Regras de Negócio Uma RN complexa não deve ser escrita como um único algoritmo complexo. Quebre uma RN complexa em várias regras mais simples. Evite utilizar aninhamentos, variáveis, contadores e outros elementos algorítmos. O momento de escrever a RN é o momento de pensar no negócio e não no sistema. A RN deve ser facilmente compreendida por qualquer pessoa que tenha um mínimo de conhecimeno do problema/negócio. A RN deve expressar o O QUÊ deve ser avaliado ou garantido e não COMO, ONDE, QUEM, QUANDO ou POR QUÊ. A definição da RN não deve escrever nada além do QUÊ deve ser avaliado. Não devemos descrever QUEM é responsável pela sua manutenção nem POR QUÊ ela é necessária. Adicionar palavras apenas pra dar ênfase não é recomendável, por exemplo: “Se a soma dos períodos de tempo durante os quais o sinistro esteve aberto é maior do que 30 dias, então o sinistro deve prescrever sob qualquer hipótese.” Nesse caso, o termo sublinhado é desnecessário. 66
  • 67. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 O verbo “ter” deve ser evitado, pois possui semântica fraca e gera ambiguidade. Evite omitir detalhes que possam alterar o entendimento da regra. Inclua toda o contexto necessário para a execução da regra, por exemplo: “Um pedido não pode ser finalizado se o valor excede o limite de crédito.” Valor de quê? Limite de crédito de quem? Revendo a regra teríamos: “Um pedido não pode ser enviado se o valor total do mesmo excede o limite de crédito da conta do cliente.” Para representação das RNs são recomendadas duas formas que são: • Tabelas de decisão • Se...Então...Senão A opção de usar uma ou outra forma é uma decisão do analista de requisitos em conjunto com o time. 7.7.2 Tabelas de Decisão A RN é representada através de uma tabela onde cada coluna representa uma condição ou ação e cada linha representa uma regra. Veja o exemplo da tabela 7.1: Descrição da Regra: o valor da franquia é definido para a apólice e pode ser ou não aplicável ao sinistro de acordo com a natureza/causa/evento do sinistro, conforme tabela abaixo: [RN001] – Aplicação do Valor da Franquia Evento do Sinistro Aplicar Franquia Incêndio, raio ou explosão Sim Diferente de incência, raio ou Não explosão Tabela 7.1: Regra de Negócio em Tabela de Decisão 67
  • 68. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 7.7.3 Se-Então-Senão A RN é representada como um conjunto de premissas independentes entre si no seguinte formato: SE <condições>, então <ação a ser tomada> senão <ação a ser tomada>. Exemplo: [RN001] – Aplicação do Valor da Franquia Se o evento que ocasionou o sinistro for incêndio, raio ou explosão, então deverá ser aplicada a franquia, senão a franquia não deverá ser aplicada. Quadro 7.1: Regra de Negócio em Se-Então-Senão 8. Principais Artefatos do Time de Requisitos 8.1 Especificação de Requisitos de Software (extraído do RUP) A SRS (Especificação de Requisitos de Software) concentra-se na coleta e na organização de todos os requisitos que envolvem o projeto. É útil para coletar os requisitos de software do projeto em um documento formal no estilo do IEEE830. Como você pode se deparar com diferentes ferramentas para coletar esses requisitos, é importante entender que a coleta dos requisitos pode ser feita com vários e diferentes artefatos e ferramentas. Por esse motivo, coletaremos os requisitos para a nossa SRS em um pacote que pode consistir em um único documento ou em um conjunto de diversos artefatos que descrevem os requisitos. O pacote SRS controla a evolução do sistema em toda a fase de desenvolvimento do projeto; quando novos recursos são adicionados ou modificados no documento Visão, eles são elaborados dentro desse pacote. A Especificação de Requisitos de Software é utilizada por estas pessoas: • Os designers utilizam o Pacote SRS como uma referência ao definir responsabilidades, operações e atributos nas 68
  • 69. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 classes e ao ajustar as classes no ambiente de implementação. • Os implementadores consultam o Pacote SRS para entrada ao implementar classes. • O Coordenador de Projeto consulta o Pacote SRS para entrada ao planejar iterações. • Os testadores utilizam o Pacote SRS como uma entrada para consideração dos testes que serão necessários. . 8.2 Especificações Suplementares (extraído do RUP) As Especificações Suplementares capturam os requisitos do sistema que não são prontamente capturados no no modelo de caso de uso. Entre os requisitos estão incluídos: • Requisitos legais e de regulamentação e padrões de aplicativo • Atributos de qualidade do sistema a ser criado, incluindo requisitos de usabilidade, confiabilidade, desempenho e suportabilidade • Outros requisitos, como aqueles para os sistemas e ambientes operacionais, compatibilidade com outro software e restrições de design 8.3 Glossário (extraído do RUP) Existe um Glossário para o sistema que fornece um conjunto consistente de definições que ajudam a evitar interpretações erradas. Os membros do projeto utilizam inicialmente esse artefato para compreender termos que são específicos do projeto. Esse documento também é importante para pessoas que desempenham as seguintes funções: 69
  • 70. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • Desenvolvedores, que utilizam os termos do Glossário ao projetar e implementar classes, tabelas de banco de dados, interfaces com o usuário e assim por diante • Analistas, que utilizam o Glossário para capturar termos específicos do projeto para que possam definir claramente regras de negócios e assegurar que as especificações de requisitos usem esses termos de forma correta e consistente • Desenvolvedores de Cursos e escritores técnicos, que utilizam o Glossário para construir material e documentação de treinamento com uma terminologia reconhecida 8.4 Modelo de Casos de Uso (extraído do RUP) Esse artefato é um modelo das funções pretendidas do sistema e seu ambiente, e serve como um contrato estabelecido entre o cliente e os desenvolvedores. É utilizado como fonte de informações essencial para atividades de análise, design e teste. O Modelo de Casos de Uso deve servir como um meio de comunicação e pode servir como um contrato entre o cliente, os usuários e os desenvolvedores do sistema sobre a funcionalidade do sistema, que permite: • que clientes e usuários validem que o sistema ficará como eles esperavam. • que os desenvolvedores do sistema construam o que é esperado. O modelo de caso de uso consiste em casos de uso e atores. Cada caso de uso do modelo é descrito detalhadamente, mostrando passo a passo como o sistema interage com os atores, e o que o sistema faz no caso de uso. Estas são as pessoas que utilizarão o modelo de casos de uso: • O cliente aprova o modelo de casos de uso. Depois de obter a aprovação, você saberá qual é o sistema que o cliente deseja. Você também pode utilizar o modelo para discutir o sistema com o cliente durante a fase de desenvolvimento. 70
  • 71. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • Possíveis usuários utilizam o modelo de casos de uso para conhecer melhor o sistema. • O arquiteto de software utiliza o modelo de casos de uso para identificar a funcionalidade da arquitetura. • Os designers utilizam o modelo de casos de uso para obter uma visão geral do sistema. Por exemplo, quando você refina o sistema, precisa da documentação sobre o modelo de casos de uso para ajudá-lo no trabalho. • O gerente utiliza o modelo de casos de uso para planejar e acompanhar a modelagem do caso de uso e também o design subseqüente. • Pessoas que não participam do projeto, mas trabalham na organização, executivos e comitês gerais de trabalho utilizam o modelo de casos de uso para ter uma idéia do que foi feito. • O modelo de casos de uso é revisado para oferecer regularmente feedback adequado aos desenvolvedores . • Os designers utilizam o modelo de casos de uso como base para seu trabalho. • Os testadores utilizam o modelo de casos de uso para planejar as atividades de teste (caso de uso e teste de integração) o mais cedo possível. • Aqueles que desenvolverão a próxima versão do sistema utilizam o modelo de casos de uso para saber como a versão atual funciona. • Os redatores da documentação utilizam os casos de uso como base para redigir os guias do usuário do sistema. . 8.5 Pedido dos Envolvidos (extraído do RUP) Este artefato contém qualquer tipo de pedido dos envolvidos (cliente, usuário, pessoal de marketing, etc.) em relação ao sistema que será 71
  • 72. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 desenvolvido. Ele também pode conter referências a qualquer tipo de fonte externa com a qual o sistema deve estar de acordo. A finalidade deste artefato é capturar todos os pedidos feitos em relação ao projeto e o modo como eles foram abordados. Embora o analista de sistema seja responsável por esse artefato, várias pessoas contribuirão para ele: pessoal de marketing, usuários, clientes - qualquer pessoa considerada como um envolvido no resultado do projeto. Essas informações podem ser coletadas em um documento ou ferramenta automatizada e os pedidos apropriados devem ser controlados e relatados seguindo um processo de CRM (Gerenciamento de Controle de Mudanças). Exemplos de origens dos Pedidos dos Envolvidos: • Resultados das entrevistas dos envolvidos • Resultados das sessões e dos workshops de identificação de requisitos • CR (Controle de Mudanças) • Relatório de trabalho • Pedido de proposta • Declaração da missão • Declaração do problema • Regras do negócio • Leis e regulamentações • Sistemas legados • Modelo de Negócios 8.6 Plano de Gerenciamento de Requisitos (extraído do RUP) Esse artefato descreve os artefatos de requisitos, os tipos de requisitos e seus respectivos atributos de requisitos, especificando as informações a serem coletadas e os mecanismos de controle a serem utilizados para avaliar, relatar e controlar as mudanças feitas nos requisitos do produto. Um Plano de Gerenciamento de Requisitos deve ser desenvolvido para especificar as informações e os mecanismos de controle que serão 72
  • 73. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 coletados e utilizados para avaliar, relatar e controlar as mudanças feitas nos requisitos do produto. A finalidade do Plano de Gerenciamento de Requisitos é descrever como o projeto configurará e gerenciará os produtos de trabalho de requisitos, os tipos de requisitos associados e atributos de requisitos. O plano também mostra como a rastreabilidade será gerenciada. 8.7 Visão (extraído do RUP) Esse artefato define a visualização de envolvidos do produto a ser desenvolvido, especificada em termos de suas necessidades e recursos mais importantes. Ele contém uma descrição dos requisitos centrais pretendidos e, portanto, proporciona a base contratual para requisitos técnicos mais detalhados. Este artefato fornece uma base de alto nível, algumas vezes contratual, para os requisitos técnicos mais detalhados que são visíveis para os envolvidos. Ele captura a "essência" da solução imaginada na forma de requisitos de alto nível e de restrições de design que fornecem ao leitor uma visão geral do sistema a ser desenvolvido a partir de uma perspectiva de requisitos comportamentais. Fornece entrada para o processo de aprovação do projeto e, portanto, está intrinsecamente relacionado ao Produto de Trabalho. O documento de visão é escrito a partir da perspectiva do cliente, focalizando os recursos essenciais do sistema e os níveis de qualidade aceitáveis. A Visão deve incluir uma descrição dos recursos que serão incluídos, bem como daqueles considerados, mas não incluídos. Ela também deve especificar capacidades operacionais (volumes, tempos de resposta, exatidões), perfis de usuários (quem utilizará o sistema) e interfaces interoperacionais com entidades externas ao limite do sistema, onde aplicável. O documento Visão fornece uma visão completa do sistema de software em desenvolvimento e serve de suporte ao contrato entre a autoridade financeira e a organização de desenvolvimento. Todo projeto precisa de uma origem para capturar as expectativas entre os envolvidos. 73
  • 74. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 9. UML 9.1 O que é a UML UML – Unified Modeling Language, ou simplesmente Linguagem Unificada de Modelagem é uma linguagem ou notação de diagramas utiizada para especificar, visualizar e documentar modelos de software. A UML não é um método de desenvolvimento, desta forma, não indica a ordem em que deve ser utilizada, apenas oferece uma variedade de recursos, na forma de diagramas, que podem ser utilizados em diferentes momentos do ciclo de desenvolvimento do software. A UML ajuda a visualizar o produto que será construído e apoia a comunicação. É formada por elementos que são usados para criar diagramas, que podem representar uma determinada parte do sistema ou um ponto de vista do mesmo. 9.2 Para que serve a UML Dentre as diversas utilizações da UML podemos citar: • Ajuda a pensar antes de c odificar • Ajuda na aparesentação de ideias ao grupo • Aumenta a participação e o envolvimento do time • Documenta as ideias quando já consolidadas • Facilita o atendimento dos requisitos • Reduz o esforço de manutenção • Facilita a alteração do software • Reduz o re-trabalho: reparos ocorrem a nível de projeto • Melhora a gestão do conhecimento: permite consolidar o projeto na empresa e não nas pessoas 9.3 Falta de Alinhamento entre Cliente, Analista e Time A falta de alinhamento entre clientes, analistas e time de desenvolvimento é, sem dúvidas, um dos motivos do fracasso de projetos de 74
  • 75. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 software. Muitas vezes clientes sabem o que querem mas não sabem expressar exatamente. Analistas pensam que sabem o que o cliente quer e não analisa o problema corretamente, e por fim, o time de desenvolvimento entende, de maneira errada, o que era pra ser feito. Com isto acabamos por desenvolver a solução errada e o nosso projeto é considerado fracassado. Este cenário, é demonstrado na figura 9.1. Figura 9.1: Falta de alinhamento entre Cliente, Analista e Time de Desenvolvimento A UML pode ser considerada uma forte aliada para resolver este problema. Uma vez que o sistema a ser construído é modelado previamente, teremos uma maior chance de entendimento comum entre clientes, analistas e desenvolvedores. 9.4 Aprovação do Cliente Para que cada etapa do processo de desenvolvimento aconteça de forma satisfatório é preciso obter o envolvimento do cliente, tanto no momento da análise do problema, da definição dos requisitos mas também para aprovação da solução. É preciso investigar o problema cuidadosamente e, a partir do momento em que se concebe uma solução, esta deverá ser modelada e apresentada à todos os interessados, com o objetivo de obter a 75
  • 76. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 validação e aprovação. Isto permitirá uma melhor comunicação entre os envolvidos e a obtenção de uma espécie de contrato de trabalho que define qual o escopo da solução, ou seja, o que fará e o que não fará parte do trabalho. 9.5 Modelagem Para que se consiga um entendimento comum, através de um processo de comunicação mais eficaz, a modelagem é uma grande aliada. Ela permite que diversos modelos sejam gerados de acordo com a fase do projeto, o tipo de requisito a ser demonstrado e, até mesmo, qual o público alvo do modelo. Por exemplo, podemos criar um modelo mais complexo para apresentar ao time de desenvolvimento e um modelo mais simples para apresentar ao cliente. O modelo do cliente poderá omitir detalhes técnicos não necessários ao entendimento da solução. Para abordamos uma realidade com a abordagem sistêmica precisamos de modelos, o que favorece a possibilidade de fazermos simulações, facilitando assim a definição de soluções para os problemas existentes na realidade em questão. O domínio da complexidade pode ser dividio em 3 categorias, sendo: sistema, modelo e simulação. O sistema representa uma visão da realidade, o modelo é uma representação simplificada da realidade e a simuloação é uma experimentação. Tais categorias são demonstradas na figura 9.2. Figura 9.2: Domínio da Complexidade 76
  • 77. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 9.6 Motivação para Utilização de Modelagem Da mesma forma que para construir uma casa é preciso desenhar sua planta, para construir um software é preciso desenhar sua arquitetura. É preciso ter uma representação visual do sistema, antes que ele entre na etapa de implementação. É preciso estabelecer uma padronização para facilitar a comunicação entre analistas e time de desenvolvimento e entre analistas e cliente. Um modelo pode ser criado independente de sua implementação, ou seja, a qualquer momento uma implementação pode ser trocada por outra, sem afetar o modelo. 9.7 Tipos de Diagramas da UML Um diagrama é uma apresentação gráfica de um conjunto de elementos, geralmente representados como gráficos de vértices (itens) e arcos (relacionamentos). Dentre os principais tipos de diagramas da UML estão: • Diagrama de classes • Diagrama de objetos • Diagrama de pacotes • Diagrama de casos de uso • Diagrama de sequência • Diagrama de colaboração • Diagrama de estados • Diagrama de atividades • Diagrama de componentes • Diagrama de implantação Diagrama de Classes: são a espinha dorsal da maioria dos métodos orientados a objeto, inclusive UML. Descrevem a estrutura estática do sistema (classes e relacionamentos). Diagrama de Objetos: descrevem a estrutura estática de um sistema em um determinado momento. Podem ser usados para testar a precisão dos diagramas de classe. 77
  • 78. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Diagrama de Pacotes: organizam elementos do sistema em grupos relacionados a fim de minimizar a dependência entre eles. Diagrama de Casos de Uso: modelam a funcionalidade do sistema através de atores e casos de uso. Casos de uso são serviços ou funções fornecidas pelo sistema aos seus usuários. Diagrama de Sequência: descreve as interações entre as classes através das trocas de mensagens ao longo do tempo. Diagrama de Colaboração: representam as interações entre objetos em termos de mensagens em sequência. Descrevem tanto a estrutura estática como o comportamento dinâmico do sistema. Diagrama de Estados: descrevem o comportamento dinâmico do sistema em resposta a estímulos externos.São especialmente úteis para modelar objetos reativos cujos estados são disparados por eventos específicos. Diagrama de Atividades: ilustram a natureza dinâmica de um sistema modelando o fluxo de controle de uma atividade por outra. Uma atividade representa uma operação em uma classe do sistema que resulta na mudança do estado do sistema. Tipicamente, são usados para modelar fluxo de trabalho ou processos de negócio e funcionamento interno. Diagrama de Componentes: descreve a organização dos componentes físicos de software. Diagrama de Implantação: descrevem os recursos físicos em um sistema, incluindo nós, componentes e conexões. Conhecer e estudar todos os diagramas da UML é importante para todos os profissionais de TI, porém nos próximos capítulos daremos ênfase aos diagramas mais utilizados pelos analistas de requisitos, o diagrama de Atividades e o diagrama de Casos de Uso. 9.8 Características da UML Dentre as principais características da UML podemos citar: • A UML é independente da linguagem de programação 78
  • 79. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • Alguns diagramas podem modelar software orientado a objetos ou não • Define uma linguagem formal para a modelagem e não para a implementação • Não existe a necessidade de utilização de todos os diagramas, a equipe deve definir quais diagramas serão utilizados em cada etapa do processo de desenvolvimento • Não existe ordem pré-definida para construção dos diagramas 10. Diagrama de Atividades 10.1 O que é o Diagrama de Atividades O Diagrama de Atividades é um diagrama da UML utilizado para modelar o aspecto comportamental de processos. Uma atividade é modelada como uma sequência estruturada de ações. Em seu aspecto mais simples, um diagrama de atividades pode ser confundido com um fluxograma, no entando, o Diagrama de Atividades possui algumas particularidades e recursos adicionais. 10.2 Elementos do Diagrama de Atividades Dentre os principais elementos do Diagrama de Atividades estão: • Estado Inicial • Estado Final • Atividades • Transição entre Estados de Atividades • Raias • Ramificações • Sincronizações (bifurcação e união) 79
  • 80. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 10.2.1 Estado Inicial Um círculo preenchido seguido por uma seta apontando para uma certa atividade (ação), define que se trata do estado de atividade (ação) inicial (onde inicia o fluxo de controle). No exemplo abaixo, “Preparar Mensagem de Crédito” é o estado inicial do Diagrama de Atividades: Figura 10.1: Estado Inicial do Diagram de Atividades 10.2.2 Estado Final Podemos definir que um certo estado de atividade (ação) é o final através de uma seta apontando para um círculo que inclui um outro círculo interno preenchido, conforme a Figura 10.2. Neste caso, o estado de atividade (ação) “Avaliação dos Resultados” é o estado final do Diagrama de Atividades correspondente. Figura 10.2: Estado Final do Diagrama de Atividades 10.2.3 Atividade Uma atividade é uma execução não atômica (é composta de um conjunto de ações) visando a mudança de estado de uma certa classe de um sistema ou o retorno de um certo valor. As ações de uma atividade são atômicas, isto é, não se dividem em outras ações. As ações podem se 80
  • 81. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 constituir em cálculos específicos, chamadas de outras operações, envio de sinais ou mensagens, criação ou destruição de objetos. A Figura 10.3 demonstra a atividade Preparar Mensagem de Crédito. Figura 10.3: Exemplo de Atividade 10.2.4 Transição entre Estados de Atividades A Transição Entre Atividades é representada por uma seta que diz de qual e para qual estado de atividade (ação) o fluxo deve seguir, no exemplo da Figura 10.4, existe uma transição entre estados de “Contactar Interruptor de Crédito” para “Acessar Resultados do Interruptor”. Figura 10.4: Transição entre Estados de Atividades 81
  • 82. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 10.2.5 Rais O Diagrama de Atividades pode ser dividio em grupos e posicionados dentro de rais. Cada atividade deve ficar em uma única raia e as transições podem cruzar as diversas raias. As rais são úteis para se modelar processos de negócios (associa-se a cada raia um setor da organização, um subprocesso ou um responsável). A Figura 10.5 demonstra um diagrama de atividades formado por 2 rais denominadas sucessivamente de Grupo 1 e Grupo 2. Figura 10.5: Diagrama de Atividades com Raias 10.2.6 Ramificações Um Diagrama de Atividades mostra o fluxo de atividades (ações) que não são sempre sequenciais. Quando se tem caminhos alternativos, que são seguidos em função de uma certa condição, usa-se a ramificação. Um losangulo representa uma decisão com caminhos alternativos. A saída da alternativa deve ser rotulada com uma condição ou expressão. Pode-se ainda rotular apenas um dos caminhos. Veja o exemplo da Figura 10.6. 82
  • 83. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Figura 10.6: Diagrama de Atividades com Ramificação 10.2.7 Sincronizações Um diagrama de atividades mostra o fluxo de atividades (ações) que não são sempre sequenciais. Quando se tem caminhos concorrentes, usa-se a sincronização, que é representada graficamente por uma barra (horizontal ou vertical). A sincronização pode-se consituir em: • Bifurcação (forking): divisão de um mesmo fluxo em dois ou mais fluxos concorrentes. • União (joining): sincronização de um ou mais fluxos concorrentes em um único. Neste caso, cada fluxo que chegar a este ponto , aguarda até que todos os outros tenham chegado. Vejamos o exemplo apresentado na Figura 10.7. 83
  • 84. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Figura 10.7: Diagrama de Atividades com Forking e Joining 11. O Modelo de Casos de Uso 11.1 O que é o Modelo de Casos de Uso O Modelo de Casos de Uso é um link entre necessidades dos stakeholders e requisitos do software. Ele define o limite do sistema, captura e comunica o comportamento, identifica quem ou o quê interage com o sistema e é bastante útil para validar e verificar os requisitos. É formado por pelo menos 2 artefatos, o Diagrama de Casos de Uso, onde as funcionalidades do sistema são representadas de forma gráfica, e pela Especificação de Casos de Uso, onde são detalhados cenários de utilização do software. 11.2 Diagrama de Casos de Uso O Diagrama de Casos de Uso auxilia a comunicação entre analistas e clientes. Descreve um cenário que monstra as funcionalidades do sistema, do ponto de vista do usuário. O cliente deve ver no Diagrama de Casos de Uso as principais funcionalidades do sistema. O Diagrama de Casos de Uso descreve ainda o sistema, seu ambiente e a relação entre os dois. São utilizados para obter requisitos do 84
  • 85. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 sistema a partir da perspectiva do usuário. Acompanha todo o ciclo de desenvolvimento do sistema, sendo utilizado pelos analistas de requisitos, arquitetos, desenvolvedores, testers e demais envolvidos. 11.2.1 Elementos do Diagrama de Caso de Uso O Diagrama de Casos de Uso é representado por Atores, Casos de Uso e Relacionamentos. Os relacionamentos podem ser do tipo Associação, Generalização, Extensão ou Inclusão. 11.2.1.1 Ator Ator é um elemento que está fora do sistema. De alguma forma e em algum momento ele interaje com o sistema. Pode ser um usuário, um equipamento ou mesmo outro sistema, desde que tenha interação com o sistema que está sendo modelado. O Ator não deve ser identificado pelo nome, por exemplo João, mas sim pelo papél que ele desempenha na aplicação, por exemplo, Gerente, Secretária, Balconista, Atendente. O Ator não é parte do sistema, ele age no ambiente do sistema, interage ativamente com o sistema e pode representar um ser humano, uma máquina ou outro sistema. A Figura 11.1 demonstra o formato de um Ator no Diagrama de Casos de Uso. Figura 11.1: Ator 85
  • 86. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 11.2.1.2 Papél Podemos definir um papél considerando, por exemplo, o caso de múltiplos personagens representados por um Ator em uma peça de teatro. Neste caso, você como Ator poderia representar o papel de bandido ou policial. O Ator representa um papel e não um usuário individual. A figura 11.2 representa as várias possibilidades de papeis para um Ator. Figura 11.2: Papéis de um Ator 11.2.1.3 Caso de Uso Um Caso de Uso é representado pela figura de uma elípse. Identifica uma funcionalidade do sistema que gera valor para o Ator. O nome do Caso de Uso deve começar por um verbo de ação (fazer, realizar, registrar, etc...) pois ele indica uma ação que o Ator pode realizar ao interagir com o sistema. Casos de Uso descrevem ações que entregam valor para o Ator. Mostra as fucnionalidades do sistema sendo utilizadas pelo Ator. Modela um diálogo entre Ator e Sistema e desta forma, representa um sistema pela perspectiva do Ator. A figura 11.3 demonstrar a interação entre Atores e Sistema, através dos Casos de Uso. 86
  • 87. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Figura 11.3: Interação entre Ator e Casos de Uso 11.2.1.4 Relacionamentos do Caso de Uso O Diagrama de Casos de Uso pode apresentar alguns tipos de relacionamentos, podendo ser, relacionamentos entre Atores e Casos de Uso, entre Casos de Uso e Casos de Uso e entre Atores e Atores. Os relacionamentos representam uma conexão entre os elementos e definem o comportamento dos mesmo. 11.2.1.5 Associação Uma Associação pode ocorrer entre um Ator e um Caso de Uso. A associação é representada no diagrama através de uma ligação simples entre o Ator e o Caso de Uso. Este é o único tipo de relacionamento que pode ocorrenr entre um Ator e um Caso de Uso. A Figura 11.4 representa uma associação onde, em algum momento, o Ator poderá acionar a funcionalidade (caso de uso) “Fazer Pedido”. 87
  • 88. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Figura 11.4: Associação entre Ator e Caso de Uso 11.2.1.6 Inclusão Um relacionamento de inclusão mostra a dependência entre dois casos de uso, o que significa que um caso de uso incorpora o comportamento de outro caso de uso. O relacionamento de inclusão pode ocorrer apenas entre dois casos de uso. A figura 11.5 demonstra a utilização de um relacionamento de inclusão entre dois casos de uso, neste caso, toda vez que a funcionalidade (caso de uso) “Pagar Conta” for acionada automaticamente a funcionalidade (caso de uso) “Definir Forma de Pagamento” també será acionada. O relacionamento de inclusão é definido por uma seta tracejada com o rótulo <<include>> ou <inclusão>>. A seta sai do primeiro caso de uso que será acionado em direção ao segundo caso de uso que será “disparado”. Figura 11.5: Relacionamento Inclusão 11.2.1.7 Extensão Um relacionameno de extensão define uma relação entre dois casos de uso onde o segundo caso de uso pode ou não incorporar o outro, 88
  • 89. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 ou seja, ao acionar um caso de uso principal o Ator poderá escolher se deseja ou não acionar o segundo caso de uso, o coportamento é opcional e não obrigatório como no caso do relacionamento de inclusão. O relacionamento de exensão é demonstrado através de uma seta traseja que sai do caso de a ser extendido para o caso de uso principal e possui o rótulo <<extende>> ou <<extensão>>. A Figura 11.6 demonstra a utilização do relacionamento de extensão, neste caso, ao acionar a funcionalidade (caso de uso) pagar conta o Ator terá a opção de acionar ou não a funcionalidade (caso de uso) Cancelar Pagamento. Figura 11.6: Relacionamento Extensão Agrupando os dois exemplos teremos um cenário onde ao acionar o caso de uso Pagar Conta o Ator automaticamente acionará o caso de uso Definir Forma de Oagamento e poderá ou não (ação opcional) acionar o caso de uso Cancelar Pagamento, conforme demonstrado na Figura 11.7. Figura 11.7: Utilização de Inclusão e Extensão 89
  • 90. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 11.2.1.8 Generalização A generalização é um tipo de associação entre Atores, ela representa uma herança entre os atores, ou seja o Ator filho herda o acesso à todas as funcionalidades do Ator Pai. A Generalização é representada por uma seta fechada. A seta sai do Ator Filho (que herda as funcionalidades) em direção ao Ator Pai (que possui acesso às funcionalidades), conforme demonstrado na Figura 11.8. Neste exemplo o Ator Gerente herda as funcionalidades do Ator Atendente. Figura: 11.8 Herança entre Atores 12. Especificação de Casos de Uso 12.1 O que é a especificação de um Caso de Uso A especificação de um caso de uso é uma descrição narrativa de uma sequencia de eventos que ocorrem quando um Ator (agente externo) usa um sistema para relizar uma tarefa. 12.2 Benefícios dos Casos de Uso • Permite a contextualização dos requisitos o Coloca os requisitos do sistema em uma sequencia lógica o Ilustra o porque da necessidade do sistema o Ajuda na verificação de que todos os requisitos foram capturados 90
  • 91. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • São fáceis de entender o Utiliza terminologia que o cliente e usuários entendem o Conta história concreta de uso do sistema o Vefirica o entendimento dos stakeholders o Ajuda na comunicação e entendimento do time • Facilita a validação do cliente o Facilita a criação de test cases, documentação e design o Facilita reuso de requisitos • Possui metodologia de estimativa: Pontos de Casos de Uso 12.3 Desvantagens dos Casos de Uso • Não possui um processo ágil • Não é um documento técnico • Existem N maneiras de escrever seus fluxos • Não é recomendado escrever operações sistêmicas, sem interação com um Ator (schedules) • Não possui informações sobre design da interface com o usuário • O analista de requisitos precisa lembrar o time técnico a estimar a implementação das regras de negócio, requisitos especiais e requisitos não funcionais 12.4 Quando Utilizar Casos de Uso • Bons candidatos o Comportamentos que podem ser capturados usando uma sequencia de ações o Comportamentos observáveis externamente • Maus candidatos o Comportamentos que não podem ser descritos como uma sequencia de ações • Perguntas que ajudam na identificação o Quais são os objetivos de cada ator? 91
  • 92. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 o Por que o ator deseja utilizar o sistema? o O ator irá criar, armazenar, alterar, remover ou consultar algum dado no sistema? Se sim, por quê? o O ator precisa informar ao sistema sobre eventos externos ou mudanças? o O ator precisa ser informado sobre alguma ocorrência? o O sistema suporta o negócio com todos os comportamentos necessários? 12.5 Nomeando Casos de Uso Não existe um único padrão a ser adotado para nomear os casos de uso. É preciso alinhar o formato de nomes com os demais artefatos do projeto, no entanto sugere-se a utilização do padrão: UC999-<verbo no infinitivo> + Objeto [qualificado]>, onde: • UC – prefixo para caracterizar o objeto tipo Caso de Uso • 999 – sequencial numérico • <verbo no infinitivo> - descrição da ação esperada do sistema • <objeto [qualificado]> - descrição do objeto associado à ação esperada do sistema Exemplos de nomes de casos de uso: Especificação de casos de uso do tipo CRUD UC001 – Manter Cadastro de Clientes Pessoa Física Especificação de casos de uso do tipo funcional UC002 – Aprovar Análise de Risco UC003 – Regularizar Pagamento Rejeitado Exemplos a serem evitados: Emitir relatórios (relatório de que?) 92
  • 93. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 12.6 Elaboração em Fases O ideal é somente inicar a descrição da especificação dos casos de uso quando as features tiverem sido aprovadas pelo cliente. A natureza deste tipo de documento é que o processo de criação seja realizado de forma iterativa. Para casos de uso mais complexos, pode-se adotar a elaboração de um diagrama de Atividades para tratar o comportamento dos desvios e/ou utilizar outros métodos de levamtamento como storyboard e/ou protótipos para validar o entendimento. A elaboração de casos de uso em fases (de forma iterativa) possui quatro etapas, conforme demonstrado na Figura 12.1. Figura 12.1: Elaboração de casos de uso de forma iterativa Identificado (Discovered): os casos de uso identificados devem ser documentos no artefato Modelo de Casos de Uso e validados com o Cliente. Breve Descrição do Caso de Uso (Briefly Described): fazer uma breve descrição das funcionalidades que serão atendidas pelo caso de uso. 93
  • 94. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Descrever Principais passos (Outlined): descrever os principais passos do Fluxo Principal e Identificar os Fluxos Alternativos. Completamente Descrito (Fully Described): um caso de uso normalmente é descrito por completo na fase de Macro Design de uma iteração do ciclo de vida do projeto, ou em algumas vezes, uma determinada iteração contemplará a descrição completa de apenas uma parte dos fluxos e a outra iteração irá completar os demais fluxos. 12.7 Seções da Especificação de Casos de Uso O documento de especificação de casos de uso deverá conter: • Introdução • Breve Descrição • Diagrama de Casos de Uso • Atores • Pré-condições • Pós-Condições • Fluxo Principal • Fluxo Alternativo • Fluxo de Exceção 12.7.1 Introdução • Deverá conter: o Breve descrição do objetivo o Escopo o Público-alvo do documento o Visão geral da estrutura do documento • Poderá conter: o Lista dos documentos que foram utilizados para a elaboração, entendimento ou que são referenciados/acionados pelo documento. 94
  • 95. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 12.7.2 Breve Descrição Descreve a finalidade do caso de uso. A descrição deve prover informações suficientes para se entender a aplicabilidade do caso de uso antes mesmo da leitura de seus fluxos. Diretrizes: • Escreva pouco • Inicie a descrição com: “Este caso de uso é responsável por...” • Ou: “Este caso de uso permite que o ator realize...” • Para os casos de uso mais complexos, insira figuras que ilustrem/facilitem o entendimento, porém garanta a conscistência com o detalhamento do caso de uso (exceto figuras de diagramas UML, pois o documento terá um seção específica para isto) 12.7.3 Diagrama de Casos de Uso Deverá ilustrar apenas o contexto em que este caso de uso está inserido, apresentando os atores e demais casos de uso com os quais este se relaciona (exemplo: inclusões e extensões). 12.7.4 Atores Deverão ser listados todos os atores que apresentam relação com o caso de uso a ser descrito. Listar apenas os nomes relacionados com o caso de uso. Nomeie os atores seguindo o padrão: AT999-<nome do ator>, onde: • AT – prefixo para caracterizar o objeto tipo Ator • 999 – sequencial numérico do ator, sendo um sequencial único par ao projeto, ou seja, não deverá ser diferente por caso de uso • <nome do ator> - nome que identifica o ator. 95
  • 96. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 12.7.5 Pré-Condições É uma condição obrigatoriamente verdadeira ou um estado no qual o sistema se encontra antes do caso de uso começar. Não é um evento que inicia o caso de uso. As pré-condições reduzem a necessidade de validações dentro do fluxo de eventos do caso de uso. Uma pré-condição nunca deve se referir a outros casos de uso que devem ser realizados anteriormente a este caso de uso. A sessão de pré-condição pode ser utilizada quando estamos descrevendo um caso de uso de extensão ou de inclusão que recebe informações do caso de uso base. A nomeclatura de uma pré-condição deve seguir o padrão: PR999<descrição da pré-condição>, onde: • PR – prefixo para caracterizar o objeto tipo pré-condição • 999 – sequencial numérico • <descri ção da pré-condição> - descrição resumida da pré- condição Exemplo: PR001 – Para que o caso de uso seja iniciado é necessário que o telefone esteja com o status de ocupado. 12.7.6 Pós-Condições Descreve o estado do sistema no fim da execução de um caso de uso. Normalmente é utilizado quando esse estado é pré-condição para execução de outro caso de uso. Em muitas situações a pós-condição pode ser ocultada, quando o resultado do caso de uso é óbvio, ou ainda nos casos onde a execução do mesmo não causa alterações significantes no estado do sistema. Quando você usa pós-condições junto com relacionamentos de extensão, deve tomar cuidado para que o caso de uso extendido não viole a pós-condição do caso de uso base. A nomeclatura de uma pós-condição deve seguir o padrão: PS999 - <Descrição da pós-condição>, onde: • PS – prefixo para caracterizer o objeto tipo pós-condição • 999 – sequencial numérico 96
  • 97. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • <Descrição da pós-condição> - descrição resumida da póscondiçào Exemplo: PS001 – Ao final deste caso de uso, o telefone terá o status alterado para desligado. A pré-condição e a pós-condição são demonstradas na Figura 12.2. Figura 12.2: Pré e Pós-Condição 12.7.7 Fluxo de Eventos Deve possuir a descrição dos passos do caso de uso e a ordem de execução destes passos. As principais partes do fluxo de eventos são o Fluxo de Eventos Principal (também chamado de Fluxo Básico), Fluxo Alternativos e Fluxo de Exceção. Eles descrevem os dados que são trocados entre o ator e o caso de uso: • O usuário preenche as informações... • O sistema calcula... • O usuário confirma... 97
  • 98. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 12.7.7.1 Fuxo Principal Apresenta a realização dos principais objetivos do Caso de Uso. Esse fluxo representa um cenário de sucesso do início ao fim. Deve descrever passo a passo o fluxo normal, ou “caminho feliz”, sob o ponto de vista do Ator. Deve enumerar os passos de execução do fluxo com uma seqüência numérica, especificar como o Sistema será usado e não como será implementado. Um Fluxo Principal nunca deve tratar Erros e desvios de fluxo. Em casos de Uso do tipo CRUD normalmente o Fluxo Principal apresenta uma lista inicial com a apresentação das operações que podem ser realizadas (Inclusão, Consulta, Alteração ou Exclusão), e estas operações são documentadas como Fluxos Alternativos. Quando não for mencionar uma lista inicial com operações, devemos deixar o fluxo de inclusão como sendo um fluxo principal. 12.7.7.1.1 Início do Fluxo Principal Deverá descrever como o Caso de Uso começa e termina (ex.: “Este Caso de Uso tem início quando o ator Gerente seleciona a opção de Cadastrar Novo Cliente”) 12.7.7.1.2 Tratamento de Condições Evite frases condicionais como “se” e “caso”, pois na maioria das vezes eles devem ser tratados como fluxos alternativos / exceção para representar o comportamento a ser seguido pelo sistema a partir de uma determinada condição. Como o Fluxo Principal deve ser entendido como sendo um fluxo de entendimento independente dos demais fluxos do Caso de Uso Não é boa prática colocar a referência de um fluxo alternativo ou de exceção dentro do fluxo Principal. Aconselha-se sempre descrever no início de um Fluxo Alternativo ou de Exceção onde aquele fluxo pode ser iniciado. Veja exemplo no Quadro 12.1 98
  • 99. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Este caso de uso inicia-se quando o ator... : 1. O Usuário .... 2. O Sistema ... 3. O Usuário ... 4. O Sistema... 5. O Caso de Uso termina. Quadro 12.1: Fluxo Principal 12.7.7.1.3 Referenciando Outros Casos de Uso Para os casos de extensão ou inclusão de um Caso de Uso Abstrato, identificar no texto qual o Caso de Uso deverá ser acionado para execução do passo no fluxo de eventos. Exemplo: Referenciando outros Casos de Uso FA1 – Pagamento por Cartão de Crédito No passo 12 do Fluxo Principal, caso o pagamento seja em cartão de crédito, o sistema executa os seguintes passos: 1. O sistema aciona o caso de uso “UC002 – Efetuar pagamento em Cartão de Crédito”. 2. O sistema verifica que o pagamento foi realizado com sucesso e retorna o fluxo ao mesmo passo de onde foi chamado. Quadro 12.2: Caso de uso com referência para outro caso de uso 12.7.7.2 Fluxo Alternativo Apresentam os comportamentos opcionais ou condicionais do Caso de Uso. Esses fluxos podem ser considerados desvios do Caso de Uso, em algumas situações voltam ao fluxo básico e em outras finalizam a execução do Caso de Uso. Cada fluxo alternativo representa um comportamento alternativo geralmente devido a escolhas realizadas pelo ator para alcançar seu objetivo. Caso não existam tratamentos opcionais ou condicionais para o Caso de Uso, preencher esta seção com Não se Aplica. O início do fluxo alternativo deve situar onde o mesmo pode ser iniciado (localização), como por exemplo: 99
  • 100. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Exemplos: - Este Fluxo Alternativo inicia-se quando o ator é o Sistema ABC e este solicita um serviço para atualizar faltas. [ou] - No passo 1 do Fluxo Principal, o Usuário seleciona a Inclusão de um Novo Curso. Quadro 12.3: Fluxo Alternativo Toda vez que for referenciar um passo do Fluxo Principal, Fluxo Alternativo ou Fluxo de Extensão, deve-se utilizar referência cruzada (recurso da ferramenta Word), para facilitar a manutenção do documento. O tamanho dos fluxos alternativos poderá ser tão extenso quanto o necessário para descrever os eventos associados ao comportamento alternativo. Um Fluxo Alternativo pode acionar outros Fluxos Alternativos. Fluxos alternativos poderão retornar para o fluxo principal e assim encontrar o caminho para finalizar o caso de uso ou poderão eles mesmos finalizar a execução do sistema. Caso o fluxo alternativo retorne ao fluxo principal, determine claramente para que passo do fluxo principal deve-se retornar. Isso deve ser explicitamente determinado. Se o fluxo for retornar a um passo posterior ao qual ele foi acionado, deve-se utilizar a palavra “continua”. Se o fluxo for retornar para o mesmo passo em que foi acionado, deve-se utilizar o texto: Exemplo: “O fluxo retorna para o mesmo passo de onde foi chamado”. Quadro 12.4: Retorno no Fluxo Alternativo Se o fluxo for retornar a um passo anterior ao qual ele foi acionado, deve-se utilizar a palavra “retorna”. Exemplo: - O fluxo alternativo é iniciado no passo 3 do Fluxo Principal e se, após a execução, ele for retornar ao passo 1, o fluxo alternativo deve finalizar com o texto “O fluxo retorna ao passo 1 do fluxo Principal”. Quadro 12.5: Retorno no Fluxo Alternativo II 100
  • 101. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 12.7.7.2.1 Identificando Fluxos Alternativos Para nomear os fluxos alternativos devemos utilizar o prefixo denominado como “FA” seguido de um seqüencial numérico, um hífen e o nome do fluxo alternativo, conforme padrão: FA999 - <nome do Fluxo Alternativo>, onde: • FA – prefixo para caracterizar o objeto tipo Fluxo Alternativo • 999 – sequencial numérico • <Nome do Fluxo Alternativo> - nome que identifica o Fluxo Alternativo Exemplo de fluxo alternativo: Exemplo Caso de Uso “Manter Layouts” Fluxo Principal ... 4. Para cada layout recuperado, o sistema exibe suas informações de identificação. ... Fluxos Alternativos FA6 – Exportação de Layout em XML No passo 4 do Fluxo Principal, caso o usuário deseje exportar um layout em XML a partir de um layout informado, o sistema executa os seguintes passos: a. O usuário informa o local onde o arquivo gerado deverá ser armazenado e solicita a exportação. b. O sistema recupera o registro do layout e grava, no local informado pelo usuário, o arquivo XML com as informações recuperadas. c. O caso de uso termina. Quadro 12.6: Exemplo de Fluxo Alternativo 12.7.7.3 Fluxo de Exceção Os fluxos de exceção devem mostrar como o sistema deve se comportar nas situações de erro de negócio. Descrevem os procedimentos que devem ser adotados no caso de erros durante os fluxos principal e alternativos. Caso não existam tratamentos de situações de erro para o Caso de Uso, preencher esta seção com Não se Aplica. 12.7.7.3.1 Identificando Fluxos de Exceção Para nomear os fluxos de exceção devemos utilizar o prefixo denominado como “FE” seguido de um seqüencial numérico, um hífen e o nome do fluxo exceção, conforme padrão FE999-<nome do Fluxo de Exceção>, onde: 101
  • 102. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 • FE – prefixo para caracterizar o objeto do tipo Fluxo de Exceção • 999 – sequencial numérico • <nome do Fluxo de Exceção> - nome que identifica o Fluxo de Exceção Exemplo de fluxo de exceção: Exemplo Caso de Uso “Realizar Inscrição” Fluxo Principal ... 4.Para cada disciplina selecionada, o sistema aloca o aluno em uma turma que apresente uma oferta para tal disciplina. 5. O sistema informa as turmas nas quais o Aluno foi alocado. ... Fluxos Exceção FE1 – Não há oferta disponível No passo 4 do Fluxo Principal, o sistema identifica que não há oferta disponível para alguma disciplina selecionada pelo aluno, a. O sistema reporta o fato através da mensagem (MSG002). b. O caso de uso termina. Quadro 12.7: Exemplo de Fluxo de Exceção 102
  • 103. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Referências Bibliográficas ÁVILA, Ana Luiza & SPÍNOLA, Rodrigo Olibeira. Introdução à Engenharia de Requisitos. Engenharia de Software Magazine. São Paulo. Edição 01. Páginas 46-51. FAGUNDES, Rodrigo Moreira. Engenharia de Requisitos. São Paulo, 2011. FILHO, Wilson de Pádua Paula. Alguns Fundamentos da Engenharia de Software. Engenharia de Software Magazine. São Paulo. Edição 1. Páginas 4-8. IIBA. Um Guia para o Corpo de Conhecimento de Análise de Negócios – BABOK 2.0. São Paulo, 2011. IBM. RUP – Rational Unified Process Ver 7.1.1. Disponível na Internet via http://www.wthreex.com/rup/v711_ptbr/index.htm. Acessado em 06/01/2014. LEFFINGWELL, Dean & WIDRIG, Don. Gerenciamento de Requisitos de Software. São Paulo, 2000. MORAES, Janaína Bedani Dixon. Introdução a Abordagem de Identificação de Requisitos. Engenharia de Software Magazine. São Paulo. Edição 02. Páginas 54-58. NEVES, Marcelo. Análise de Negócios para Curiosos. São Paulo, 2012. SOUSA, Vinícius Lourenço de. Desenvolvimento de Software Dirigido por Caso de Uso. Engenharia de Software Magazine. São Paulo. Edição 02. Páginas 36-40. SOUSA, Vinícius Lourenço de. Desenvolvimento de Software Dirigido por Caso de Uso – Parte II. Engenharia de Software Magazine. São Paulo. Edição 03. Páginas 14-21. 103
  • 104. Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2 Links para Templates de Artefatos do RUP Artefato Link Plano de Gerenciamento de http://www.wthreex.com/rup/v711_ptbr/formal_r Requisitos esources/guidances/templates/resources/rup_r mpln.dot Stakeholder Request http://www.wthreex.com/rup/v711_ptbr/formal_r esources/guidances/templates/resources/rup_st kreq.dot Glossário de Termos http://www.wthreex.com/rup/v711_ptbr/formal_r esources/guidances/templates/resources/rup_gl oss.dot Documento Visão http://www.wthreex.com/rup/v711_ptbr/formal_r esources/guidances/templates/resources/rup_vi sion.dot Especificação de Requisitos http://www.wthreex.com/rup/v711_ptbr/formal_r esources/guidances/templates/resources/rup_sr s.dot Especificação Suplementar http://www.wthreex.com/rup/v711_ptbr/formal_r esources/guidances/templates/resources/rup_s spec.dot Modelo de Casos de Uso http://www.wthreex.com/rup/v711_ptbr/formal_r esources/guidances/templates/resources/rup_u cspec.dot 104