Aula06-Requisitos

(1)

Engenharia de Software

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

Departamento de Ciências Exatas

Prof. Jorge Dias www.jorgediasjr.com

jorge@dce.ufpb.br

(2)

(3)

Ok Sobre as

orelhas.

Situação típica

(4)

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

(5)

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

(6)

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? Como é que funciona uma imobiliária?

Aplicação inexistente

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

(7)

Engenharia de Requisitos

Definição

A Engenharia de Requisitos, uma sub-área da Engenharia de Software, estuda o

processo de definição dos requisitos que o software deverá atender.

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

(8)

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

(9)

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 Um levantamento de requisitos mal feito pode comprometer o

(10)

Conceitos

Requisitos

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

---Engenharia de Requisitos

(11)

Engenharia de Requisitos

Processo (Sommerville, 2008)

Estudo de viabilidade Elicitação e análise de requisitos Especificação de requisitos Validação de requisitos Gerenciamento de requisitos

(12)

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

O documento pode propor ainda mudanças no

enfoque

, no

orçamento

e no

cronograma

do projeto, e considerar

questões como

integração

com outros sistemas e escolha de

(13)

Viabilidade Técnica

Questões

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

Já possuímos a tecnologia necessária?

Já possuímos o conhecimento técnico necessário?

(14)

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 desejáveis

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

(15)

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

(16)

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 sobre os requisitos do sistema

(17)

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) omissão de detalhes considerados de conhecimento geral)

Saber identificar requisitos iguais, apresentados de maneiras

distintas

(18)

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

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 Usuários têm muitas necessidades

puramente políticas

Usuários não sabem priorizar suas

necessidades

Desenvolvedores querem definir o

que os usuários devem fazer

Desenvolvedores não conseguem

transformar necessidades em um sistema de sucesso

(19)

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

Visão dos Usuários

Desenvolvedores estão sempre

atrasados

Desenvolvedores sempre querem

mais tempo e menos esforço compromissados com o projeto

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

permanecem dentro do planejamento

mais tempo e menos esforço

Desenvolvedores são incapazes

de atender rapidamente as necessidades de modificação

(20)

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

Oportunidade para

identificar erros

de

procedimentos,

problemas de relacionamento

(hierarquia) e

estrutura do ambiente

(Ex: distribuição

de funcionários por setor)

(21)

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

(22)

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

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

(23)

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

(24)

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 objetivos da entrevista

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

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

(25)

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 Procurar ajudar em vez de criticar Escolher perguntas simples

Falar pouco, ouvir mais

Evitar contradizer o entrevistado

(26)

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)

(27)

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

(28)

Técnicas para Levantamento de Requisitos

Técnica 5: Técnica Mista

Combinação de técnicas para obter melhores

resultados

(29)

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 De Domínio

Uso de

diagramas

, linguagem natural ou estruturada,

(30)

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 Dependem do tipo de softwaretipo de software, dos , dos usuáriosusuários e do e do sistema sistema

esperado

Costumam ser descritos na forma de verbos

(31)

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

(32)

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

(33)

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

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?

(34)

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}

(35)

Classificação de R. N. F.

Requisitos do Produto

Produto deve comportar-se de forma particular (velocidade de execução,

confiabilidade, etc.)

Exemplo: [RNF001] Toda consulta ao B.D., baseada em código de barras, deve

resultar em até 5 s

Requisitos Organizacionais

Conseqüência de políticas e procedimentos organizacionais (padrões de Conseqüência de políticas e procedimentos organizacionais (padrões de

processo usados, requisitos de implementação, etc.)

Exemplo: [RNF002] Todos os documentos entregues devem seguir o padrão de

relatórios XYZ-00

Requisitos Externos

Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento

(legislação, etc.)

Exemplo: [RNF003] Informações pessoais do usuário não devem ser vistas pelos

(36)

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 domínio da aplicação, dificultando a compreensão por parte do desenvolvedor

Exemplos: cálculo de multa ou desconto, restrição de um

(37)

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

lugar

(38)

Prioridade

Requisitos podem ser vistos em três classes distintas

Essenciais Importantes Desejáveis

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

(39)

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 Prioridade: Importante

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

resultados

(40)

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 É preciso evitar custos desnecessários e retrabalho (requisitos

(41)

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

(42)

Gerenciamento de Requisitos

Gerenciamento de requisitos é o processo de

controlar as mudanças dos requisitos durante

O processo da engenharia de requisitos

O desenvolvimento do sistema

(43)

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

(44)

Rastreabilidade

Responsável por dependências entre requisitos,

suas origens e projeto do sistema

Rastreamento de Origem

Associação entre requisitos e stakeholders que

(45)

(46)

Rastreabilidade

Rastreamento de Requisitos

Associação entre requisitos dependentes

Rastreamento de Projeto

Associação dos requisitos com o projeto

(47)

1.

Rastrear requisitos do usuário nos do sistema

2.

Rastrear requisitos no projeto

3.

Req A 1 Requisitos Produto (Caracter.)

Rastreabilidade

3.

Rastrear requisitos nos procedimentos de teste

4.

Rastrear requisitos do usuário no plano Projeto Modelos Suítes Teste Teste 2 3 1 Requisitos Detalhados (Casos de Uso) Req B Plano Doc. Usuário 4

(48)

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

RF01 RF02 RF03

RF01

X

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

RF02

(49)

Casos de Uso

(50)

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

Modelo de caso de uso

Atores

Casos de Uso

Especificação de casos de uso

Documento textual contendo a

descrição do caso de uso

Casos de Uso

Especificações de Use Case ...

(51)

Diagrama de Caso de Uso

Função Emissor/Receptor

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

Emissor/Receptor

(52)

Use Case e Ator

A to r P a rt ic u la r R e su lt a d o d e V a lo r O b se rv á v e l Função Emissor Função Receptor A to r P a rt ic u la r R e su lt a d o d e V a lo r O b se rv á v e l

(53)

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

(54)

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

(55)

Exemplo de Use Case e Ator

Transferir Valor de resultado observável Cliente Transferir dinheiro Sacar dinheiro Consultar saldo

(56)

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?

Receber o cartão de volta? Receber o cartão de volta?

(57)

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 Satisfaz um objetivo particular de um ator que o sistema deve

(58)

Identificando Use Cases

Facilitar gerenciamento durante ciclo de desenvolvimento

(59)

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

(60)

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

(61)

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

programas

(62)

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

(63)

Inclusão

Descrição de

Consultar saldo

Fluxo de Eventos Principal:

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

(64)

Extensão

Use case pode ser estendido por outro

Extensão de funcionalidade/Caso excepcional

Extensão ocorre em pontos específicos

(65)

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 Representar comportamentos opcionais Lidar com exceções

(66)

Extensão

<< extend >> (urgente) Atender Pontos de extensão urgente Atender urgência

(67)

Extensão

Descrição de

Atender

Fluxo de Eventos Principal:

(68)

Especialização

Use case pode especializar outro

Adição/refinamento do fluxo de eventos original

Especialização permite modelar comportamento de estruturas

(69)

Especialização

Atender Atender urgência

∆

Atender Atender urgência

∆

Cliente Cliente comercial

(70)

Exemplo de Diagrama

Transação de cartão Cliente Sistema de validação de cartão de crédito Cliente corporativo Cliente individual Cliente _{Instituição} vendedora Financeira Processa fatura Reconcilia transações Gerencia conta

(71)

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

Geralmente em linguagem natural

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

problema

Também expresso formalmente

(72)

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

(73)

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

(74)

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

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”

(75)

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

(76)

Exemplo de Fluxo de Eventos

FE-01: Cartão inválido

1.

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

(77)

Exemplo de Fluxo de Eventos

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

1.

O sistema informa que senha é inválida

2.

O sistema solicita senha novamente

(78)

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

(79)

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

(80)

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

(81)

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;

(82)

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

(83)

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. 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. As páginas devem ser desenvolvidas em Java e o banco de dados deve ser