guia de estudos introdução à engenharia de requisitos

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

Introdução à Engenharia de Requisitos Rodrigo Gomes da Silva – RMUC 1 / RMUC 2

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.


3

Sumário

1. Melhores Práticas da Engenharia de Software 7 1.1 Sintomas dos Problemas de Desenvolvimento de Software 7 1.2 As Seis Melhores Práticas da Engenharia de Software 7 1.2.1 Melhor Prática 1 – Desenvolvimento Iterativo 8 1.2.2 Melhor Prática 2 – Gestão de Requisitos 10 1.2.3 Melhor Prática 3 – Arquitetura Baseada em Componentes 10 1.2.4 Melhor Prática 4 – Modelagem Visual – UML 11 1.2.5 Melhor Prática 5 – Verificação Contínua da Qualidade 11 1.2.6 Melhor Prática 6 – Gestão de Configuração e Mudança 11 2. RUP e as Melhores Práticas da Engenharia de Software 12 2.1 RUP e as Melhores Práticas da Engenharia de Software 12 2.1.1 Definição de Processos no RUP 16 2.1.2 Fases do Ciclo de Vida do RUP 17 3. Engenharia de Requisitos 19 3.1 Engenharia de Software 19 3.2 O que são Requisitos? 21 3.3 Tipos de Requisitos 22 3.4 Engenharia de Requisitos 23 3.4.1 Produção de Requisitos 25 3.4.1.1 Levantamento 25 3.4.1.2 Registro 25 3.4.1.3 Verificação 25 3.4.1.4 Validação 26 3.4.2 Gerência de Requisitos 26 3.4.2.1 Controle de Mudanças 26 3.4.2.2 Gerência de Configuração 26 3.4.2.3 Rastreabilidade 27 3.4.2.4 Gerência de Qualidade de Requisitos 27 4. Disciplina de Requisitos 28 4.1 O que os Requisitos de Software Especificam? 28 4.2 Definições Importantes 28 4.3 Alguns Exemplos 29 4.4 Dificuldade em Gerenciar Requisitos 29 4.5 Qualidade dos Requisitos 30 4.6 Disciplina de Requisitos no RUP 31 4.7 Principais Artefatos da Disciplina de Requisitos 33 5. Análise do Problema 34 5.1 Entendendo o Problema 34 5.2 Passos para Análise do Problema 40 5.3 Identificando as Restrições do Sistema 40 5.4 Identificando os Limites do Sistema 41 5.5 Needs (necessidades) dos Stakeholders e do Negócio 41 5.6 Features (características) do Software 42 5.7 Requisitos do Software 43 5.8 Capturar Vocabulário Comum 43 6. Entendendo a Necessidade do Stakeholder 44 6.1 Capturando Necessidades 44 6.2 Atividades e Artefatos 44 6.3 Problemas a Serem Encontrados 44 6.4 Artefato Stakeholder Request (Pedidos dos Envolvidos) 45 6.5 Elicitação de Requisitos 47 6.5.1 Brainstorming 47 6.5.1.1 Vantagens do Bradinstorming 48 6.5.1.2 Desvantagens do Brainstorming 48 6.5.2 Análise de Documentos 48 6.5.2.1 Vantagens da Análise de Documentos 49 6.5.2.2 Desvantagens da Análise de Documentos 50 6.5.3 Workshop de Requisitos 50


4

6.5.3.1 Vantagens do Workshop de Requisitos 51 6.5.3.2 Desvantagens do Workshop de Requisitos 51 6.5.4 Entrevistas 52 6.5.4.1 Vantagens da Entrevista 53 6.5.4.2 Desvantagens da Entrevista 53 6.5.5 Observação 54 6.5.5.1 Vantagens da Observação 55 6.5.5.2 Desvantagens da Observação 56 6.5.6 Outras Técnicas Importantes 56 6.5.7 Obstáculos da Elicitação de Requisitos 56 7. Atividades de Requisitos 57 7.1 Especificação de Requisitos 57 7.2 Requisitos Funcionais 57 7.2.1 Exemplos de Requisitos Funcionais 58 7.3 Requisitos Não Funcionais 58 7.3.1 Exemplos de Requisitos Não Funcionais 58 7.4 Planejar o Processo de Gerenciamento de Requisitos 58 7.4.1 Repositório 59 7.4.2 Rastreabilidade 59 7.4.3 Selecionar Atributos dos Requisitos 59 7.4.4 Processo de Priorização dos Requisitos 61 7.4.5 Gerenciamento de Mudanças 62 7.4.6 Gerenciar o Escopo e os Requisitos da Solução 63 7.4.7 Gerenciar de Conflitos 64 7.5 Apresentando Requisitos para Revisão 64 7.5.1 Aprovação 65 7.6 Comunicar os Requisitos 65 7.7 Regras de Negócio 65 7.7.1 Recomendações para Regras de Negócio 66 7.7.2 Tabelas de Decisão 67 7.7.3 Se-Então-Senão 68 8. Principais Artefatos do Time de Requisitos 68 8.1 Especificação de Requisitos de Software 68 8.2 Especificações Suplementares 69 8.3 Glossário 69 8.4 Modelo de Casos de Uso 70 8.5 Pedido dos Envolvidos 71 8.6 Plano de Gerenciamento de Requisitos 72 8.7 Visão 73 9. UML 74 9.1 O que é a UML 74 9.2 Para que serve a UML 74 9.3 Falta de Alinhamento entre Cliente, Analista e Time 74 9.4 Aprovação do Cliente 75 9.5 Modelagem 76 9.6 Motivação para Utilização de Modelagem 77 9.7 Tipos de Diagramas da UML 77 9.8 Características da UML 78 10. Diagrama de Atividades 79 10.1 O que é o Diagrama de Atividades 79 10.2 Elementos do Diagrama de Atividades 79 10.2.1 Estado Inicial 80 10.2.2 Estado Final 80 10.2.3 Atividade 80 10.2.4 Transição entre Estados de Atividades 81 10.2.5 Rais 82 10.2.6 Ramificações 82 10.2.7 Sincronizações 83 11. O Modelo de Casos de Uso 84 11.1 O que é o Modelo de Casos de Uso 84


5

11.2 Diagrama de Casos de Uso 84 11.2.1 Elementos do Diagrama de Caso de Uso 85 11.2.1.1 Ator 85 11.2.1.2 Papél 86 11.2.1.3 Caso de Uso 86 11.2.1.4 Relacionamentos do Caso de Uso 87 11.2.1.5 Associação 87 11.2.1.6 Inclusão 88 11.2.1.7 Extensão 88 11.2.1.8 Generalização 90 12. Especificação de Casos de Uso 90 12.1 O que é a especificação de um Caso de Uso 90 12.2 Benefícios dos Casos de Uso 90 12.3 Desvantagens dos Casos de Uso 91 12.4 Quando Utilizar Casos de Uso 91 12.5 Nomeando Casos de Uso 92 12.6 Elaboração em Fases 93 12.7 Sessões da Especificação de Casos de Uso 94 12.7.1 Introdução 94 12.7.2 Breve Descrição 95 12.7.3 Diagrama de Casos de Uso 95 12.7.4 Atores 95 12.7.5 Pré-Condições 96 12.7.6 Pós-Condições 96 12.7.7 Fluxo de Eventos 97 12.7.7.1 Fuxo Principal 98 12.7.7.1.1 Início do Fluxo Principal 98 12.7.7.1.2 Tratamento de Condições 98 12.7.7.1.3 Referenciando Outros Casos de Uso 99 12.7.7.2 Fluxo Alternativo 99 12.7.7.2.1 Identificando Fluxos Alternativos 101 12.7.7.3 Fluxo de Exceção 101 12.7.7.3.1 Identificando Fluxos de Exceção 101 Referências Bibliográficas 103 Links para Templates de Artefatos do RUP 104


6

Lista de Figuras Figura 1.1: Desenvolvimento em Cascata 9 Figura 1.2: Desenvolvimento Iterativo 9 Figura 2.1: RUP – Gráfico de Baleias 13 Figura 2.2: Desenvolvimento Iterativo e Incremental 14 Figura 2.3: Relação entre Ferramentas e as Seis melhores Práticas da Engenharia de Software 16 Figura 3.1: Custo de manutenção de sistemas 20 Figura 3.2: Fatores Críticos no Desenvolvimento de Software 21 Figura 3.3: Engenharia de Requisitos 24 Figura 4.1: Fluxo de Atividades de Requisitos do RUP 32 Figura 4.2: Papéis e artefatos da disciplina de requisitos do RUP 33 Figura 5.1: Representação do Problema 35 Figura 5.2: Relação espaço do problema X espaço da solução 36 Figura 9.1: Falta de alinhamento entre Cliente, Analista e Time de Desenvolvimento 75 Figura 9.2: Domínio da Complexidade 76 Figura 10.1: Estado Inicial do Diagram de Atividades 80 Figura 10.2: Estado Final do Diagrama de Atividades 80 Figura 10.3: Exemplo de Atividade 81 Figura 10.4: Transição entre Estados de Atividades 81 Figura 10.5: Diagrama de Atividades com Raias 82 Figura 10.6: Diagrama de Atividades com Ramificação 83 Figura 10.7: Diagrama de Atividades com Forking e Joining 84 Figura 11.1: Ator 85 Figura 11.2: Papéis de um Ator 86 Figura 11.3: Interação entre Ator e Casos de Uso 87 Figura 11.4: Associação entre Ator e Caso de Uso 88 Figura 11.5: Relacionamento Inclusão 88 Figura 11.6: Relacionamento Extensão 89 Figura 11.7: Utilização de Inclusão e Extensão 89 Figura: 11.8 Herança entre Atores 90 Figura 12.1: Elaboração de casos de uso de forma iterativa 93 Figura 12.2: Pré e Pós-Condição 97

Lista de Tabelas Tabela 4.1: Principais Artefatos da Disciplina de Requisitos do RUP 33 Tabela 5.1: exemplo de hierarquia entre Needs, Features e Requisitos 36 Tabela 5.2: Needs identificadas 38 Tabela 5.3: Features identificadas 38 Tabela 5.4: Requisitos identificados 39 Tabela 7.1: Regra de Negócio em Tabela de Decisão 67

Lista de Quadros Quadro 5.1: Exemplo de descrição do problema 37 Quadro 5.2: Desejo dos Stakeholders 37 Quadro 6.1: Conteúdo do Documento Stakeholder Request 46 Quadro 7.1: Regra de Negócio em Se-Então-Senão 68 Quadro 12.1: Fluxo Principal 99 Quadro 12.2: Caso de uso com referência para outro caso de uso 99 Quadro 12.3: Fluxo Alternativo 100 Quadro 12.4: Retorno no Fluxo Alternativo 100 Quadro 12.5: Retorno no Fluxo Alternativo II 100 Quadro 12.6: Exemplo de Fluxo Alternativo 101 Quadro 12.7: Exemplo de Fluxo de Exceção 102


7

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;


8

• 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;


9

• 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


10

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.


11

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


12

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.


13

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.


14

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


15

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;


16

• 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.


17

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;


18

• 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.


19

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.


20

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


21

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 sub-

disciplina 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


22

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.


23

• 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,


24

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.


25

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.


26

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.


27

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.


28

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.


29

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 caixa-

preta, 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


30

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


31

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


32

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.


33

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 Características

Documento Visão Identificação do problema

Identificação dos Atores e Usuários


34

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.


35

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.


36

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 Feature Requisitos RF001 RF002 RF003

FE001

RF004 RF005 RF006 RF007

FE002

RF008 RF009

NE01

FE003 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


37

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


38

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 ID Feature

FE001 Manter Professores

FE002 Validar Professores

NE001 Gerenciar Cadastro

de Professores

FE003 Gerar Relatório de Professores

NE002 Acessar Holerites FE004 Disponibilizar Holerites

FE005 Manter Disciplinas NE003 Gerenciar 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:


39

Needs

ID Descrição ID Feature 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 uma

[Senha de Acesso

Temporária]

RF004 O sistema deverá permitir a

alteração dos dados dos

professores cadastrados


exclusão de registros de

professores

RF006 Somente poderão ser

excluídos professores que

não possuem alocação de

disciplinas

NE001

Gerenciar

Cadastro de

Professores

FE001 Manter

Professores


pesquisa de professor por

meio de informação de

parâmetros: [nome] ou [id]

Tabela 5.4: Requisitos identificados


40

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:


41

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:


42

• 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


43

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


44

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


45

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


46

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)


47

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?


48

• 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.


49

A analise de documentos pode incluir analise

de planos de negocio, estudos de mercado,

contratos, requisições de propostas,

declarações de trabalho, memorandos,

orientações existentes, procedimentos, guias

de treinamentos, literatura a respeito de

produtos concorrentes, revisões

comparativas publicadas de produtos,

reportes de problemas, 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.


50

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 e focado, com a

participação das principais partes

interessadas e especialistas no assunto,

cuidadosamente selecionados, para um

período curto e intenso de 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)


51

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.


52

• 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.


53

• 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.


54

� 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


55

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.


56

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.


57

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.


58

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.


59

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 e-

mail, 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


60

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


61

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


62

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.


63

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


64

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


65

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


66

é 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.


67

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

explosão

Não

Tabela 7.1: Regra de Negócio em Tabela de Decisão


68

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


69

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:


70

• 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.


71

• 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á


72

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


73

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.


74

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


75

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


76

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


77

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.


78

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


79

• 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)


80

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


81

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


82

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.


83

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.


84

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


85

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


86

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.


87

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”.


88

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,


89

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


90

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


91

• 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?


92

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?)


93

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.


94

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.


95

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.


96

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


• <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



97

• <Descrição da pós-condição> - descrição resumida da pós-

condiçà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...


98

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


99

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.

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:

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.

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.


100

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:

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”.

Quadro 12.5: Retorno no Fluxo Alternativo II

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.

Exemplo: “O fluxo retorna para o mesmo passo de onde foi chamado”.

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”.


101

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


• <Nome do Fluxo Alternativo> - nome que identifica o Fluxo Alternativo

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:

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.


102

• FE – prefixo para caracterizar o objeto do tipo Fluxo de

Exceção


• <nome do Fluxo de Exceção> - nome que identifica o Fluxo

de Exceção

Quadro 12.7: Exemplo de 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.


103

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.


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.


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.


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.


104

Links para Templates de Artefatos do RUP

Artefato Link

Plano de Gerenciamento de

Requisitos

http://www.wthreex.com/rup/v711_ptbr/formal_r

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

guia de estudos introdução à engenharia de requisitos

Documents