Engenharia-Requisitos

Prof. Jorge Dias

www.jorgediasjr.com

jorge@dce.ufpb.br

Engenharia de Software

Engenharia de Requisitos

Universidade Federal da Paraíba – Campus IV Centro de Ciências Aplicadas e Educação

Ok Sobre as

orelhas.

Introdução

Europa [Sampaio]

 Questionário distribuído para 3.805 empresas  Maiores problemas para os profissionais:

 Especificação de requisitos (53%)  Gerência de requisitos (43%)  Documentação (36%)

Introdução



Em 1995, o Standish Group pesquisou mais de 350 empresas para

entender quais as causas dos projetos terem falhado.

1.

Requisitos incompletos (13,1%)

2.

Falta de envolvimento por parte do usuário (12,4%)

Falta de recursos (10,6%)

4.

Expectativas não realistas (9,9%)

5.

Falta de apoio dos executivos (9,3%)

6.

Modificações nos requisitos e nas especificações (8,7%)

Falta de planejamento (8,1%)

Introdução

“56% dos erros de um software podem ser rastreados para a fase de

requisitos” [Tom DeMarco, 89]



Quanto mais tarde um erro é detectado, maior o custo de corrigi-lo

Muitos erros são realizados durante a definição de requisitos



Erros típicos incluem fatos incorretos, omissões, inconsistências e

ambiguidade



Erros nos requisitos constituem uma das maiores preocupações da

Iniciando um projeto...

Problemas complexos

 Não basta mais fazer um simples controle de estoque  As exigências dos clientes crescem rapidamente



Domínio desconhecido

 Como é que funciona uma imobiliária?



Aplicação inexistente

 Se não tem um sistema semelhante para servir de base, por onde

Engenharia de Requisitos



Requisitos são identificados com os clientes de uma maneira formal

e cuidadosa

 Os clientes nem sempre conseguem descrever com exatidão o que

precisam

 Principalmente para pessoas que não são da sua área  Cada área possui um vocabulário diferente

 Nós nem sempre somos capazes de entender aspectos do negócio

 Sabemos como utilizar o computador para solucionar problemas

 Mas nem sempre sabemos como as possíveis soluções podem afetar as necessidades

do negócio do cliente

 Também possuímos nosso próprio vocabulário

 As vezes achamos que estamos falando da mesma coisa e não estamos

 Conclusão: A identificação de requisitos precisa ser cuidadosamente

Engenharia de Requisitos

Definição

 A área surgiu em 1993 com a realização do I International Symposium on

Requirements Engineering

 O processo de definição de requisitos é uma interface entre os desejos,

necessidades e limitações dos clientes e a posterior implementação desses requisitos em forma de software

A Engenharia de Requisitos, uma sub-área da Engenharia de Software, estuda o processo de definição dos requisitos que o

Requisitos - Objetivos



Estabelecer e manter um acordo com clientes e outros stakeholders

sobre o que o sistema deve fazer



Prover desenvolvedores com um melhor entendimento sobre o que

o sistema deve fazer



Definir os limites do sistema



Prover base para o planejamento

Importância



A

fase de levantamento

de requisitos é

decisiva

para o sucesso do

projeto

 A satisfação do usuário só poderá ser atingida se suas necessidades

forem compreendidas

 Um levantamento de requisitos mal feito pode comprometer o

Conceitos

Requisitos

Descrição das funções e restrições para o sistema

---

Engenharia de Requisitos

Engenharia de Requisitos

Processo (Sommerville, 2008)

de requisitos Validação de requisitos

Gerenciamento de requisitos

Estudo de Viabilidade



Descrição geral do sistema

e de como ele será utilizado dentro da

organização



Nessa fase, deve ser gerado um

relatório

indicando

se vale a pena ou

não

realizar o projeto



O documento pode propor ainda mudanças no

enfoque

, no

orçamento

e no

cronograma

do projeto, e considerar questões como

Viabilidade Técnica



Questões



A solução ou a tecnologia proposta é prática?



Já possuímos a tecnologia necessária?

Viabilidade de Cronograma



Dado nosso conhecimento técnico, os prazos dos projetos

são razoáveis?



Alguns projetos são iniciados com prazos específicos

 Você precisa determinar se os prazos são obrigatórios ou

desejáveis

 Se são mais desejáveis que obrigatórios, o analista pode propor

Viabilidade Econômica

Talvez a mais crítica

 Durante as fases iniciais do projeto, a análise da viabilidade

econômica consiste em julgar se os possíveis benefícios de solucionar o problema são ou não vantajosos

 Tão logo os requisitos específicos e soluções sejam identificados, o

analista pode levar em consideração os custos e benefícios de cada alternativa

Levantamento e Análise de Requisitos



Nessa etapa, os

membros da equipe técnica

de desenvolvimento

trabalham com o

cliente e os usuários finais

do sistema para

conhecer melhor o

domínio da aplicação



Stakeholder

: qualquer pessoa que tem influência direta ou indireta

Levantamento e Análise de Requisitos



Principais desafios

 Lidar com pedidos não realistas (não se tem noção do custo das

solicitações)

 Entender os requisitos na linguagem do negócio (uso de jargões,

omissão de detalhes considerados de conhecimento geral)

 Saber identificar requisitos iguais, apresentados de maneiras distintas  Lidar com a mudança de stakeholders na empresa

Comunicação Desenvolvedor X Usuário

Visão dos Desenvolvedores

 Usuários não sabem o que querem  Usuário pedem sem necessidade  Usuários não conseguem

transmitir o que eles querem

 Usuários têm muitas necessidades

puramente políticas

 Usuários não sabem priorizar suas

necessidades

Visão dos Usuários

 Desenvolvedores não entendem as

necessidades operacionais

 Desenvolvedores colocam muita

dificuldade em qualquer pequena solicitação

 Desenvolvedores querem definir o

que os usuários devem fazer

 Desenvolvedores não conseguem

transformar necessidades em um sistema de sucesso

Comunicação Desenvolvedor X Usuário

Visão dos Desenvolvedores

 Usuários se recusam a ter

responsabilidade pelo sistema

 Usuários não estão

compromissados com o projeto

 Usuários mudam de idéia e não

permanecem dentro do planejamento

Visão dos Usuários

 Desenvolvedores estão sempre

atrasados

 Desenvolvedores sempre querem

mais tempo e menos esforço

 Desenvolvedores são incapazes

de atender rapidamente as necessidades de modificação

Técnicas para Levantamento de Dados



Técnica 1: Observação pessoal



O analista vivencia uma

situação cotidiana

do negócio para

conhecer melhor o domínio

e confirmar as informações

obtidas



Oportunidade para

identificar erros

de procedimentos,

problemas de relacionamento

(hierarquia) e

estrutura do

ambiente

(Ex: distribuição de funcionários por setor)

Técnicas para Levantamento de Requisitos



Técnica 1: Observação pessoal



Vantagens

 Não requer tempo do cliente

 Não interfere no funcionamento do negócio



Desvantagens

 Pode causar constrangimento  Não oferece dados suficientes

Técnicas para Levantamento de Requisitos



Técnica 2: Questionário



O analista elabora um

questionário

para ser entregue aos

envolvidos e recolhido posteriormente para análise



O formulário pode ser o mesmo para todos ou

adequado ao

perfil

de cada envolvido



O formulário também pode ser usado como

roteiro

estruturado de entrevista

para detalhamento de informações

fornecidas

Técnicas para Levantamento de Requisitos



Técnica 2: Questionário



Vantagens

 Fácil aplicação (não requer gastos)  Garantia de anonimato

 Pode ser aplicado em grande quantidade de pessoas  Não requer resposta imediata



Desvantagens

 Informações fornecidas podem ser ideais e não reais

 As respostas podem ser pouco esclarecedoras (bom, ótimo, regular)  Os participantes não se sentem envolvidos no processo (frieza)

Técnicas para Levantamento de Requisitos



Técnica 3: Entrevista



Considerada a

melhor técnica

pois envolve um pouco das

outras



Requer planejamento

 Definir objetivos da entrevista

 Definir data, hora, local, duração, participantes

 Elaborar questões que sejam objetivas e adequadas ao nível intelectual

Técnicas para Levantamento de Requisitos



Técnica 3: Entrevista



Algumas dicas

 Informar o objetivo do estudo

 Transmitir confiança ao entrevistado  Procurar ajudar em vez de criticar  Escolher perguntas simples

 Falar pouco, ouvir mais

 Evitar contradizer o entrevistado

Técnicas para Levantamento de Requisitos



Técnica 3: Entrevista



Vantagens

 Perguntas podem ser incluídas, alteradas, eliminadas ou feitas em outra ordem

(flexibilidade)

 É possível motivar o entrevistado para que ele contribua



Desvantagens

 Requer recursos (principalmente tempo)

 Interpretação pode ser influenciada por empatia  Perda de tempo com conversas improdutivas

 Desmotivação do entrevistado com objetividade excessiva  Inibição dos entrevistados (medo de revelar informações)

Técnicas para Levantamento de Requisitos



Técnica 4: Seminário (Workshop)



Reunião planejada de pessoas-chave de diversas áreas com o

objetivo de obter informações gerais sobre a empresa



Vantagens

 Rápida identificação de problemas de relacionamento  Visão integrada dos problemas



Desvantagem

Técnicas para Levantamento de Requisitos



Técnica 5: Técnica Mista



Combinação de técnicas para obter melhores resultados

Especificação de Requisitos e Documentação



Elaboração de

documentos contendo os requisitos

e sua

classificação

por tipo

 Funcionais

 Não-funcionais  De Domínio



Uso de

diagramas

, linguagem natural ou estruturada,

descrição

Tipos de Requisitos

Requisitos Funcionais

 Declarações de funções que o sistema deve (ou não) oferecer e de como

o sistema deve se comportar em determinadas situações

 Dependem do tipo de software, dos usuários e do sistema esperado  Costumam ser descritos na forma de verbos

Exemplos de R.F.



[RF001] Usuário pode pesquisar todo ou um sub-conjunto do

banco de dados



[RF002] Sistema deve oferecer visualizadores apropriados para o

usuário ler documentos armazenados



[RF003] A todo pedido deve ser associado um identificador

único (PID), o qual o usuário pode copiar para a área de

armazenamento permanente da conta

Requisitos Não-Funcionais



Definem propriedades e restrições do sistema (tempo, espaço,

etc)

 Também chamados de Atributos de Qualidade



Requisitos de processo também podem especificar o uso de

determinadas linguagens de programação, método de

desenvolvimento



Requisitos não-funcionais são tão críticos quanto requisitos

funcionais

Requisitos Não-Funcionais



Devido à sua própria definição, requisitos não-funcionais são

esperados mensuráveis



Assim, deve-se associar forma de medida/referência a cada

requisito não-funcional elicitado



Exemplos de

perguntas

 Com que rapidez o sistema deve operar?  Quanta memória ele requer?

 Qual a taxa aceitável de falhas?

 Qual a linguagem de programação desejada?  Quando o produto deve ser entregue?

Medidas de Requisitos

(Não-Funcionais)

Propriedade Medida

Velocidade Transações processadas/seg Tempo de resposta do usuário/evento

Tamanho K bytes

No _{de chips de RAM}

Facilidade de uso Tempo de treinamento No _{de quadros de ajuda}

Confiabilidade Tempo médio de falhas Probabilidade de indisponibilidade Taxa de ocorrência de falhas

Robustez Tempo de reinício após falha Percentual de eventos causando falhas

Probabilidade de corrupção de dados após falha

Portabilidade Percentual de declarações dependentes do destino No _{de sistemas destino}

Tipos de Requisitos

Requisitos de Domínio

 Estão ligados aos requisitos funcionais, mas estão relacionados a regras do negócio e não aos desejos dos usuários

 São expressos com o uso de linguagens que são específicas do domínio da aplicação, dificultando a compreensão por parte do desenvolvedor  Exemplos: cálculo de multa ou desconto, restrição de um dependente

Atribuição de Prioridade



Alguns requisitos são mais urgentes que outros



É essencial determinar a prioridade dos requisitos junto ao

cliente



Requisitos de maior prioridade são considerados em primeiro

Prioridade



Requisitos podem ser vistos em três classes distintas

 Essenciais  Importantes  Desejáveis



Em princípio, sistema deve resolver todos os requisitos de

Exemplo de Prioridade



[RF001] Consulta X ao B.D. deve retornar dados A, B, C

 Prioridade: Essencial



[RNF001] Consulta X ao B.D. deve visualizar dados segundo

padrão Y

 Prioridade: Importante



[RNF010] Consulta X ao B.D. deve usar cores azuis nos

resultados

Validação de Requisitos

Tarefa difícil

 Como garantir que os requisitos listados representam exatamente o

sistema que o cliente deseja?



Tarefa importante

 É preciso evitar custos desnecessários e retrabalho (requisitos têm

Validação de Requisitos

Técnicas



Revisões de requisitos

 Inspeções feitas em conjunto pelos membros da equipe técnica e

pelos stakeholders



Prototipação

 Uma versão simplificada e provisória do sistema é gerada apenas para

dar uma visão ao cliente



Geração de casos de teste

Gerenciamento de Requisitos



Gerenciamento de requisitos é o processo de

controlar as mudanças dos requisitos durante



O processo da engenharia de requisitos

Gerenciamento de Requisitos



Requisitos são inevitavelmente incompletos e inconsistentes



Requisitos novos surgem

durante o processo de acordo

com mudanças nas necessidades do negócio e um

entendimento melhor do sistema é desenvolvido



Diferentes pontos de vista têm diferentes requisitos e

esses geralmente são contraditórios

Rastreabilidade



Responsável por dependências entre requisitos,

suas origens e projeto do sistema



Rastreamento de Origem



Associação entre requisitos e stakeholders que

propuseram tais requisitos

Rastreabilidade



Rastreamento de Requisitos



Associação entre requisitos dependentes



Rastreamento de Projeto



Associação dos requisitos com o projeto

1.

2.

3.

4.

Rastreabilidade

Matriz de rastreabilidade

 Para cada tipo de ligação

determinada, a dependência deve ser registrada

 O documento que registra estas

ligações é a Matriz de Rastreabilidade

 A tabela ao lado, exemplifica a

matriz para RF X RF

 Se alterado o RF03 pode ser que o

RF01 também seja alterado

RF01 RF02 RF03

RF01

X

RF02

Casos de Uso



Composto por 2 artefatos

 Diagrama de casos de uso

 Diagrama UML mostrando os atores e

as funções do sistema

 Especificação de casos de uso

 Documento textual contendo a

descrição do caso de uso

Modelo de caso de uso

Atores

Casos de Uso

Especificações de Use Case

Diagrama de Caso de Uso



Seqüência de ações,

executada pelo sistema, que

gera um resultado

 De valor observável  E para ator particular

Função 

Alguém ou alguma

coisa (

fora do

sistema

) que

interage com o

sistema

Use Case e Ator

Use Case e Ator



A descrição de um use case define o que o sistema faz quando o

use case é realizado



A funcionalidade do sistema é definida por um conjunto de use

Exemplo de Use Case e Ator



Cliente de banco pode usar um caixa automático para

 sacar dinheiro, transferir dinheiro ou consultar o saldo da conta



Ator:

Cliente

Exemplo de Use Case e Ator

Identificando Use Cases



Em geral, difícil decidir entre um ou vários use cases

Por exemplo, seriam use cases

 Inserir cartão em um Caixa Automático?  Entrar com a senha?

Identificando Use Cases

Representar valor observável para ator

Pode-se determinar

 De interações (seqüência de ações) com o sistema que resultam

valores para atores

 Satisfaz um objetivo particular de um ator que o sistema deve

Identificando Use Cases



Facilitar gerenciamento durante ciclo de desenvolvimento

Organizando Use Cases

Sistema pequeno não demanda estruturação

 Exemplo, seis use cases, com dois/três atores



Já sistemas maiores requerem princípios de estruturação e

organização

 Caso contrário, planejamento, atribuição de prioridades, etc.,

Reuso em Use Cases



Comportamento comum a mais de dois use cases (ou forma parte

independente)

 Pode-se modelar como use case para ser reusado



Há três possibilidades

 Inclusão  Extensão

Inclusão



Vários use cases possuem texto de fluxo de eventos

 Comum/idêntico  Sempre usado



Equivalente a fatoração feita em programação através de

sub-programas

Inclusão



Como exemplo, tanto “Sacar dinheiro” quanto “Consultar saldo”

necessitam da senha

 Pode-se criar novo use case “Autenticar usuário” e incluí-lo

Sacar

dinheiro Consultar saldo

Autenticar usuário

Inclusão



Descrição de

Consultar saldo

 Fluxo de Eventos Principal:

 include (Autenticar usuário). Sistema pede a Cliente que selecione tipo de

Extensão



Use case pode ser estendido por outro

 Extensão de funcionalidade/Caso excepcional



Extensão ocorre em pontos específicos

Extensão



Há também inclusão de texto (fluxo de eventos)

 Porém sob condições particulares



Pode ser usada para

 Simplificar fluxos de eventos complexos  Representar comportamentos opcionais  Lidar com exceções

Extensão

Extensão



Descrição de

Atender

 Fluxo de Eventos Principal:

Especialização



Use case pode especializar outro

 Adição/refinamento do fluxo de eventos original



Especialização permite modelar comportamento de estruturas

Especialização





Exemplo de Diagrama

Especificação de casos de uso

Fluxo de Eventos

 Parte mais importante de um use case

 Atividade de requisitos

 Define a seqüência de ações entre o ator e o sistema  Geralmente em linguagem natural

 Uso preciso de termos definidos no glossário de acordo com o domínio do

problema

 Também expresso formalmente

Especificação de casos de uso



Fluxo de eventos



Fluxo principal ou básico



Descreve uma seqüência de ações que serão executadas,

considerando que nada de errado acontecerá durante a execução

das ações



O início do fluxo básico deve descrever bem a condição de

início e o contexto de negócio. O ator que inicia o caso de uso

deve ser citado explicitamente

Especificação de casos de uso

Fluxo de eventos

 Fluxo alternativo

 Descrevem o que acontece quando o ator (papel que interage com o sistema) faz

uma escolha alternativa, diferente da descrita no fluxo básico, para alcançar seu objetivo

 O que pode ser feito de forma diferente?

 Fluxo de exceção

 Correspondem à descrição das situações de exceção, quando algo inesperado

ocorre na interação com o sistema

Exemplo de Fluxo de Eventos

Caso de uso Sacar dinheiro (fluxo básico)

1. O use case inicia quando o Cliente insere um cartão no CA. 2. O Sistema lê e valida informação do cartão (FE-01)

3. O Sistema solicita a senha (FA-01) 4. O Cliente entra com a senha

5. O Sistema valida a senha (FE-02) 6. O Sistema pede seleção do serviço 7. O Cliente escolhe “Sacar dinheiro”

Exemplo de Fluxo de Eventos

FA-01: Cancelar operação

1.

O cliente cancela a operação

2.

O sistema informa que operação foi cancelada e retorna para o

Exemplo de Fluxo de Eventos

FE-01: Cartão inválido

1.

O sistema informa que o cartão é inválido

Exemplo de Fluxo de Eventos

FE-02: Senha Inválida (RN_01 – Verificar senha)

1.

O sistema informa que senha é inválida

O sistema solicita senha novamente

Regras de Validação



As regras de validação tipicamente documentam a obrigatoriedade e

o tratamento de formato dos campos de entrada do sistema

 datas, limites numéricos, entre outros



Cada regra de validação deve ter uma identificação única de acordo

com um determinado padrão

Regras de Validação

Exemplo

RV_01 – Data

Data de Vencimento deve estar no formato "DDMMAAAA", onde:

DD - Dia, MM - Mês, AAAA-Ano e deve ser uma data existente

no calendário

Regras de Negócio



Descrevem as regras que estabelecem requisitos gerais para o

sistema, provenientes do próprio negócio

 normas, políticas, legislações etc



As regras de negócio podem ser descritas fora do fluxo de eventos

podendo ser apenas referenciadas nos passos do fluxo de evento do

caso de uso

 Criação de um documento de regras de negócio



Cada regra de negócio deve possuir uma identificação única de

acordo com um determinado padrão

Regras de Negócio



Exemplo

RN_01 - Tipos de dependência

Os tipos de dependência podem ser: 1 - Cônjuge;

2 - Companheiro(a);

3 - Filho(a) menor não emancipado(a); 4 - Filho(a) inválido;

5 - Pai (mãe) com dependência econômica;

6 - Enteado(a) menor não emancipado(a) com dependência econômica; 7 - Enteado(a) inválido(a) com dependência econômica;

Para fixar o assunto ...

 Que técnica de levantamento de requisitos seria mais

indicada para cada situação? Justifique.

 Existe um número muito grande de usuários do sistema que precisam

ser consultados.

 O funcionamento do sistema é simples e claro, e as atividades da

empresa não podem ser interrompidas.

 O sistema deverá integrar operações entre setores, e para isso, uma

otimização inicial dos processos é necessária.

 Existem muitas regras de negócio e as funções na empresa são bem

definidas em relação à hierarquia, ou seja, cada funcionário desempenha uma atividade específica.

Para fixar o assunto ...

 Considerando uma aplicação de comércio eletrônico de

livros e cds, classifique os requisitos abaixo em Funcionais, Não-Funcionais e de Domínio:

 Cada consulta deve demorar no máximo 1 minuto para retornar resultados.

 Não deve ser permitido que um usuário compre mais de 3 unidades de um mesmo

produto.

 Cadastrar usuário.

 Consultar livro por autor.

 Exibir menus com poucos itens e em cores diferenciadas.

 Compras feitas no cartão de crédito podem ser parceladas em até 4 vezes.  Exibir lista de CDs mais vendidos.

Bibliografia



Vasconcelos, Alexandre. Slides do Curso de Engenharia de

Requisitos



Sampaio, Julio Cesar. Engenharia de Requisitos

Sommerville, I. Software Engineering



Kruchten, P. The Rational Unified Process: An Introduction. 2nd

Ed