Aula08 - Requisitos2

Prof. Jorge Dias

www.jorgediasjr.com

jorge@dce.ufpb.br

Modelagem de Dados

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%)}  _{Testes (35%)}

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

3.

Falta de recursos (10,6%)

4.

Expectativas não realistas (9,9%)

5.

Falta de apoio dos executivos (9,3%)

Modificações nos requisitos e nas

especificações (8,7%)

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 indústria de

software

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}

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

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

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

Conceitos

Requisitos

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

---Engenharia de Requisitos

Processo de descobrir, analisar, documentar e verificar 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

integração

com outros sistemas e escolha de

tecnologias

atuais

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

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

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

 _{Isso é chamado de análise de}

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

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

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

 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

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}

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 e à experiência dos entrevistados

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

Brainstorming



É uma técnica em que as pessoas colocam tudo

que vier na cabeça com relação ao projeto.



Muito útil quando existem diversos interessados

no projeto.



É dividido em duas etapas.



Na primeira, anota-se todas as ideias que

surgirem, sem que sejam questionadas.

 Neste momento o que importa mais é a

Brainstorming



Na segunda etapa, debate-se com o grupo para

ir refinando as idéias apresentadas

anteriormente. Deixe as regras bem claras, e

defina uma pessoa (facilitador) para “comandar”

a reunião, para garantir que as regras sejam

respeitadas.



Pode ser efetiva no desenvolvimento de um

novo projeto, na fase inicial, para identificar

requisitos de alto nível, aqueles mais macros

Brainstorming



Regras para Brainstorming

 Estabeleça o objetivo da sessão  Gere quantas idéias for possível  Deixe sua imaginação livre

 _{Não admita críticas ou debates}  Ajuste e combine as idéias

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 (regras de negócio)}



Uso de

diagramas

, linguagem natural ou

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 

Ex: Cadastrar cliente, Consultar venda

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?

 _{Como o sistema poderá interagir com os}

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

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}

Especificação dos requisitos



Deve incluir:

 (1) Ambiente físico

 _{Onde o equipamento funcionará?}

 Esse funcionamento se dará em um ou vários locais?

 _{Existe alguma restrição ambiental, tal como temperatura,}

umidade ou interferência magnética?

 (2) Interfaces

 _{A entrada tem origem em outro ou outros sistemas?}  _{A saída vai para outro ou outros sistemas?}

 Existe uma maneira preestabelecida pela qual os dados

devem ser formatados?

Especificação dos requisitos

 (3) Os usuários e fatores humanos  Quem utilizará o sistema?

 _{Haverá diversos tipos de usuários?}

 _{Qual o nível de habilidade de cada tipo de usuário?}

 Que tipo de treinamento será necessário para cada tipo de

usuário?

 _{Que facilidade o usuário terá para entender e utilizar o sistema?}  _{Qual será a dificuldade para que o usuário utilize}

inadequadamente o sistema?

 (4) Funcionalidade

 _{O que o sistema realizará?}  _{Quando o sistema fará?}

 _{Existem diversos modos de operação?}

 _{Como e quando o sistema pode ser modificado ou aprimorado?}

 _{Existem limitações quanto à velocidade de execução, ao tempo de}

Especificação dos requisitos

 (5) Documentação

 _{Que documentação é necessária?}

 _{Essa documentação deve ser on-line, no formato de livro,}

ou ambos?

 A que público se destina cada tipo de documentação?  _{(6) Dados}

 Qual deverá ser o formato dos dados de entrada e saída?  Com que frequência eles serão enviados ou recebidos?  Quem precisão devem ter?

 Com que grau de precisão os cálculos devem ser feitos?  Qual será o fluxo de dados do sistema?

 _{Existem dados que devem ser mantidos por algum tempo?}  _{Recursos, segurança e garantia de qualidade...}

Estrutura de um Documento de Requisitos

(Documento de Descrição de Requisitos – DDR)

1. Introdução



2. Definição dos Requisitos do Usuário



3. Especificação dos Requisitos do Sistema

4. Arquitetura do Sistema



5. Modelos do Sistema

6. Evolução do Sistema

7. Apêndices

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

Prioridade



Requisitos podem ser vistos em três classes

distintas

 Essenciais  _Importantes  Desejáveis



Em princípio, sistema deve resolver todos os

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

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

RF03 X

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



Booch, G. et al. The Unified Modeling