ES04 - Engenharia de Requisitos

Prévia do material em texto

Engenharia de Requisitos
Profª Márcia Pantoja
marcia.pantoja@unama.br
27/09/2021
1
Introdução
• Considerada a parte mais difícil e critica da
engenharia de software.
• Clientes não sabem o que querem ou mudam muito
de ideia ao longo do projeto.
27/09/2021 2
27/09/2021 3
Engenharia de Requisitos
• Tarefas e técnicas para entender requisitos
• Inicia na comunicação e continua na modelagem.
• É adaptativa.
• Constrói uma ponte entre o projeto e a construção.
• Questões a serem respondidas:
– Como controlar as mudanças?
– Como organizar os requisitos coletados?
27/09/2021 4
Engenharia de Requisitos
• Requisitos - papel central no processo de software
– Considerados um fator determinante para o sucesso ou fracasso de
um projeto de software.
• Engenharia de Requisitos
– Levantar
– Analisar
– Documentar
– gerenciar e
– controlar a qualidade dos requisitos
27/09/2021 5
Definição
• Requisitos de um sistema são descrições dos serviços que devem ser
fornecidos por esse sistema e as suas restrições operacionais
(SOMMERVILLE, 2007).
• Um requisito de um sistema é uma característica do sistema ou a
descrição de algo que o sistema é capaz de realizar para atingir seus
objetivos (PFLEEGER, 2004).
• Um requisito é alguma coisa que o produto tem de fazer ou uma
qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON,
2006).
27/09/2021 6
O que é Requisito?
• “Condição que se deve satisfazer para alcançar um objetivo”
• “Exigência que deve ser cumprida para atingir um objetivo”
27/09/2021 7
• “Entender os requisitos de um problema está 
entre as tarefas mais difíceis enfrentadas por 
um engenheiro de software.” (Pressman, 2011)
27/09/2021 8
Importância dos Requisitos
27/09/2021 9
Identificação dos Interessados
• “Qualquer um que se beneficia de forma direta ou indireta do sistema
que está sendo desenvolvido.” (Sommerville e Sawyer)
• Além do cliente e o do desenvolvedor, que podem, naturalmente, ter
diferentes nomes e títulos, existem provavelmente:
– O pessoal de marketing,
– O pessoal de testes e garantia de qualidade.
– Gerentes de produtos.
– Gerente geral.
• “Stakeholders”
27/09/2021 10
Stakeholders
27/09/2021 11
Envolvidos
Interessados
Identificação dos Interessados
• Dificuldades:
• Cada interessado:
– Tem uma visão diferente do sistema;
– Obtém diferentes benefícios quando o sistema é desenvolvido com
êxito;
– E está sujeito a diferentes riscos caso o trabalho de desenvolvimento
venha a fracassar.
27/09/2021 12
Exemplo
• Gerentes Comerciais
– Estão interessados no conjunto de recursos que pode ser construído
dentro do orçamento e que estarão prontos para atender às
oportunidades definidas de ingresso no mercado.
• Pessoal do Marketing
– Estão interessados nas funções e recursos que irão suscitar o
mercado potencial, facilitando a venda do sistema.
27/09/2021 13
Colaboração
• Identificar áreas em comum
– requisitos com os quais os interessados concordam
• Identificar áreas de conflito
– requisitos desejados por um interessado, mas que
conflitam com os de outros interessados.
• Não significa, necessariamente, que os
requisitos são definidos por um comitê.
• Normalmente um gerente comercial ou técnico
sênior pode tomar a decisão final sobre quais
requisitos que passam pelo corte.
27/09/2021 14
Sintomas e Causas de uma Engenharia 
de Requisitos Inadequada
• Pressão do cliente para uma construção rápida do
sistema
27/09/2021 15
Sintomas e Causas de uma Engenharia 
de Requisitos Inadequada
• Problemas de Comunicação
27/09/2021 16
27/09/2021 17
Sintomas e Causas de uma Engenharia
de Requisitos Inadequada
Sintomas e Causas de uma Engenharia 
de Requisitos Inadequada
• Suposição incorreta, por parte dos stakeholders, de que
muito do assunto é evidente
27/09/2021 UFPA - Campus Universitário 
do Tocantins/Cametá 
18
Tipos de Requisitos
• Três tipos:
– Requisitos Funcionais
– Requisitos Não-Funcionais.
– Requisitos de Domínio.
27/09/2021 19
Requisitos Funcionais
• Descrevem as funcionalidades e/ou serviços do sistema;
• Descrevem como o sistema deve reagir a entradas
específicas;
• Podem ser declarações de alto nível do que o sistema
deve fazer;
• Devem descrever os serviços de sistema em detalhes;
• O que o sistema não deve fazer;
• Declarações de serviços que o sistema deve fornecer, como
o sistema deve reagir a entradas específicas e como o
sistema deve se comportar em determinadas situações.
27/09/2021 20
Exemplos
• O sistema deve permitir que qualquer usuário possa
consultar e visualizar o perfil de outro usuário do sistema.
• O usuário deve ser capaz de pesquisar em todo o conjunto
inicial de banco de dados ou selecionar um subconjunto a
partir dele.
• O sistema deve permitir aos usuários do tipo gerente
visualizar relatórios de projetos em aberto e/ou finalizados, e
seus respectivos feedbacks.
• O sistema deve fornecer telas apropriadas para o usuário ler
os documentos no repositório de documentos.
27/09/2021 21
Exemplos
• O sistema deve ser capaz de armazenar todas as
informações sobre seus clientes (RG, CPF, Nome, data de
nascimento e endereço) no banco de dados.
• O sistema deverá atribuir um identificador único (código)
para cada pedido de produtos.
• O sistema deverá cancelar automaticamente um orçamento
que tenha sido feito há mais de 30 dias e não tenha sido
transformado em venda.
27/09/2021 22
Ambiguidades em Requisitos
• A imprecisão na especificação de requisitos é
motivo de vários problemas.
– O desenvolvedor tende a interpretar o requisito da
maneira mais fácil de implementar.
• “O sistema deve oferecer telas apropriadas...”
– O que são telas apropriadas?
27/09/2021 23
Requisitos Não-Funcionais
• Definem propriedades e restrições do sistema;
• Dizem respeito ao sistema como um todo;
• São também requisitos de qualidade, como confiabilidade,
tempo de resposta e espaço em disco;
• Outros são restrições ou exigências de uso de tecnologia.
• Restrições sobre serviços ou funções oferecidos pelo
sistema tais como restrições de timing, restrições sobre o
processo de desenvolvimento, padrões, etc.
27/09/2021 24
Requisitos Não-Funcionais
• Classificações de requisitos não funcionais
27/09/2021 25
Requisitos Não-Funcionais
27/09/2021 26
Exemplo
• Requisito de Produto:
– O sistema deve ser capaz de responder até, em média, a
10 requisições por segundo.
– A interface de usuário para o LIBSYS deve ser
implementada como simples HTML, sem frames ou
applets de Java.
• Requisito Organizacional:
– O processo de desenvolvimento do sistema e os
documentos a serem entregues devem estar em
conformidade com o processo e produtos a serem
entregues definidos em XYZCo-SP.
27/09/2021 27
Exemplo
• Requisito Externo:
– O sistema não deve revelar quaisquer informações
pessoais sobre os usuários do sistema, com exceção do
nome e número de referência da biblioteca.
27/09/2021 28
Requisitos Não-Funcionais
• Outros exemplos de requisitos não funcionais:
– Requisitos de facilidade de uso. Ex.: usuários deverão
operar o sistema após um determinado tempo de treinamento.
– Requisitos de eficiência. Ex.: o sistema deverá processar n
requisições por um determinado tempo.
– Requisitos de confiabilidade. Ex.: o sistema deverá ter alta
disponibilidade. Exemplo: 99% do tempo.
– Requisitos de portabilidade. Ex.: o sistema deverá rodar em
qualquer plataforma.
– Requisitos de entrega. Ex.: um relatório de acompanhamento
deverá ser fornecido toda segunda-feira.
– Requisitos de implementação. Ex.: o sistema deverá ser
desenvolvido na linguagem Java.
27/09/2021 29
Requisitos Não-Funcionais
• Outros exemplos de requisitos não funcionais:
– Requisitos de padrões. Ex.: uso de programação
orientada a objeto sob a plataforma A.
– Requisitos de interoperabilidade. Ex.: o sistema deverá
se comunicar com o SQL Server.
– Requisitos éticos. Ex.: o sistema não apresentará aos
usuários quaisquer dadosde cunho privativo.
– Requisitos legais. Ex.: o sistema deverá atender às
normas legais, tais como padrões, leis, etc.
– Requisitos de Integração. Ex.: o sistema integra com
outra aplicação.
27/09/2021 30
Verificação de Requisitos Não-
Funcionais (RNF)
• Às vezes são de difícil verificação
• Idealmente, requisitos não-funcionais devem ser
mensuráveis
– Após a implementação, estes podem ser testados
objetivamente
27/09/2021 31
Métricas de RNF
• Velocidade
– Transações processadas por segundo
– Tempo de resposta
– Tempo de atualização de tela
• Facilidade de uso
– Tempo gasto em treinamento
– Número de frames de ajuda
27/09/2021 32
Métricas de RNF
• Confiabilidade
– Tempo médio para falhar
– Probabilidade de indisponibilidade
– Taxa de ocorrência de falhas
– Disponibilidade
• Robustez
– Tempo de reinício após uma falha
– Porcentagem de eventos que causam falhas
27/09/2021 33
Requisitos de Domínio
27/09/2021 34
Requisitos de Domínio
27/09/2021 35
• Trata-se de requisitos que são do conhecimento do
processo, do departamento e/ou da empresa
cliente.
– Por exemplo: Em um sistema de gestão de operadora de
plano de saúde, os requisitos de domínio são
conhecimentos específicos desta área de atuação, que
apenas as pessoas que estão na empresa há anos
possuem e podem detalha-las de forma precisa ao
analista de requisitos.
Requisitos de Domínio
27/09/2021 36
• Exemplos:
– O calculo da média final de cada aluno é dado pela
fórmula: (Nota1 * 2 + Nota2 * 3)/5;
– Um aluno pode se matricular em uma disciplina desde
que ele tenha sido aprovado nas disciplinas consideradas
pré-requisitos.
– Em razão das restrições referentes a direitos autorais,
alguns documentos devem ser excluídos imediatamente
ao serem fornecidos. Dependendo dos requisitos dos
usuários, esses documentos serão impressos localmente
no servidor do sistema para serem encaminhados
manualmente ao usuário ou direcionados para uma
impressora de rede.
Problemas de requisitos de
domínio
27/09/2021 37
• Requisitos do usuário
– Declarações em linguagem natural e também em
diagramas sobre as funções que o sistema deve fornecer
e as restrições sob as quais deve operar.
• Requisitos do sistema
– Um documento estruturado que estabelece
detalhadamente as funções e as restrições de sistema.
Escrito como um contrato entre o cliente e o
desenvolvedor do software.
27/09/2021 38
Requisitos do Usuário
• Devem descrever os requisitos funcionais e não
funcionais de modo compreensível pelos usuários do
sistema, que não tem conhecimentos técnicos
detalhados.
• Eles adicionam detalhes e explicam como os requisitos
de usuário devem ser fornecidos pelo sistema.
• Requisitos do usuário são definidos usando linguagem
natural, tabelas e diagramas.
• Podem ser usados como parte do contrato para a
implementação do sistema e devem,portanto, s er uma
especificação completa e consistente de todo o
sistema.
27/09/2021 39
Requisitos do Usuário
• Descreve as funções e restrições do sistema de
forma abstrata
– Inteligível pelo usuário / cliente
• Ponto de vista das necessidades da empresa
cliente
– Não indica uma solução
27/09/2021 40
Requisitos do Usuário
• Problemas com linguagem natural
1. Falta de clareza
‒ Difícil usar a linguagem de maneira precisa e sem ambigüidade,
sem produzir um documento de difícil leitura
2. Confusão de requisitos
‒ Os requisitos funcionais e os não funcionais, os objetivos
do sistema e as informações sobre o projeto podem
‒ não estar claramente definidos.
3. Fusão de requisitos
‒ Vários requisitos diferentes podem ser expressos juntos.
27/09/2021 41
Requisitos do Usuário
• Para minimizar os mal-entendidos ao redigir
requisitos de usuário, Sommerville [2007]
recomenda algumas diretrizes simples:
1. Invente um formato padrão e assegure-se de que todas
as definições de requisitos aderiram a esse formato. A
padronização de formato torna as omissões menos
prováveis e os requisitos mais fáceis de serem
verificados.
27/09/2021 42
Requisitos do Usuário
• Para minimizar os mal-entendidos ao redigir
requisitos de usuário, Sommerville [2007]
recomenda algumas diretrizes simples:
2. Use a linguagem de forma consistente - deve-se sempre
fazer distinção entre requisitos obrigatórios e desejáveis.
‒ Obrigatórios - são os que o sistema deve atender e
escritos com o uso da palavra “deve”.
‒ Desejáveis - não são essenciais e são escritos com o uso
da palavra “pode”.
27/09/2021 43
Requisitos do Usuário
• Para minimizar os mal-entendidos ao redigir
requisitos de usuário, Sommerville [2007]
recomenda algumas diretrizes simples:
3. Use destaque no texto (negrito, itálico ou cor) para
ressaltar as partes principais do requisito.
4. Evitar, sempre que possível, o uso de jargões de
informática. Contudo, inevitavelmente aparecerão
termos técnicos detalhados nos requisitos de usuário.
27/09/2021 44
Requisitos de sistema
• São descrições mais detalhadas que os requisitos
do usuário.
• Devem ser padronizados, completos e consistente.
– Usados pela equipe de desenvolvimento.
– Fazem parte do contrato.
• Eles adicionam detalhes e explicam como os
requisitos de usuário devem ser fornecedidos pelo
sistema.
27/09/2021 45
Linguagem Natural
• Não é fácil padronizar os requisitos usando
linguagem natural
• Na escada rolante dizia
– “Calçados devem ser usados”
– “Cachorros devem ser carregados”
27/09/2021 46
Linguagem Natural
• Alguns Problemas
• Falta de clareza
– Pode ser difícil uma linguagem precisa e não ambígua
• Confusão de requisitos
– Requisitos pode estar misturados com informações do
projeto
• Fusão de requisitos
– Diversos requisitos expressos juntos
27/09/2021 47
Linguagem Estruturada
• É uma forma restrita da linguagem natural
• Vantagens
– Mantém a facilidade de expressão e compreensão da
linguagem natural
– Garante algum grau de uniformidade na especificação
– Podem ser escritas formulários especiais
27/09/2021 48
Requisitos x Projeto
• Requisitos definem o que o sistema faz.
• Nem sempre dizem como ele faz (projeto).
• No entanto, requisitos incluem alguns detalhes de
projeto.
– Os requisitos são organizados de acordo com os
diferentes subsistemas.
– O sistema deve interoperar com outros sistemas
existentes.
– O uso de uma arquitetura específica pode ser um
requisito externo do sistema.
27/09/2021 49
Documento de Requisitos
27/09/2021 50
Documento de Requisitos
27/09/2021 51
Especificação de Requisitos
• É o processo de escrever os requisitos de usuário e
de sistema em um documento de requisitos.
• Idealmente, os requisitos de usuário e de sistema
devem ser:
– Claros
– Inequívocos
– De fácil compreensão
– Consistentes
– Completos
27/09/2021 52
Processos de engenharia de
requisitos
• Podem incluir quatro atividades de alto nível:
– Estudo de viabilidade;
– Elicitação e Análise;
– Especificação;
– Validação.
27/09/2021 53
Processos de engenharia de
requisitos
27/09/2021 54
Estudo de Viabilidade
• Decidir se vale a pena ou não gastar tempo e esforço
com o sistema proposto;
• Sistemas novos devem começar com um estudo da
viabilidade;
• Responder Perguntas:
– O sistema contribui para os objetivos gerais da organização?
– O sistema pode ser implementado com a tecnologia atual
dentro das restrições de custo e de prazo?
– O sistema pode ser integrado a outros?
– Que contribuição direta o sistema trará para os objetivos da
empresa?
27/09/2021 55
Relatório de Viabilidade
• O relatório pode:
– Propor mudanças no enfoque, no orçamento e/ou no cronograma;
– Sugerir outros requisitos de alto nível para o sistema;
– Simplesmente cancelar o projeto de desenvolvimento do sistema.
27/09/2021 56
Elicitação e Análise de
Requisitos
• Reúne informações sobre o sistema proposto e os
existentes.
• O objetivo é descobrir:
– O domínio de aplicação;
– Serviços que devem ser fornecidos pelo sistema;
– Restrições associadas ao domínio ou serviços;– Envolvem diversos stakeholders;
27/09/2021 57
Obtendo os requisitos
• Técnicas para levantamento de requisitos:
• Descoberta de Requisitos(Pontos de vista)
• Entrevistas
• Cenários
• Casos de Uso
• Etnografia
27/09/2021 58
Obtendo os requisitos
• Técnicas para levantamento de requisitos:
• Descoberta de Requisitos(Pontos de vista)
• Entrevistas
• Cenários
• Casos de Uso
• Etnografia
27/09/2021 59
Descoberta de Requisitos
• Processo que reúne informações sobre o sistema proposto e
os existentes para obter os requisitos de usuário e de
sistema.
• Em uma empresa de tamanho médio ou grande, existem
vários stakeholders;
• Cada stakeholder tem um ponto de vista diferente
• Cada um vê o problema de modo diferente;
• Objetivo: conhecer o problema por várias perspectivas
27/09/2021 60
Descoberta de Requisitos
• Stakeholders frequentemente:
– Não sabem na realidade o que querem;
– Não conseguem expressar claramente o que desejam;
– Fazem pedidos não realistas;
– Se expressam com seus próprios termos (técnicos).
– Diferentes stakeholders expressam o mesmo requisito de forma
diferente.
27/09/2021 61
Obtendo os requisitos
• Técnicas para levantamento de requisitos:rta de
Requisitos(Pontos de vista)
– Entrevistas
– Cenários
– Casos de Uso
– Etnografia
27/09/2021 62
Entrevistas
• Questionar os stakeholders sobre o sistema (ou processo)
atual e sobre o sistema que será desenvolvido;
• Tipos de entrevistas:
– Entrevistas fechadas: conjunto pré-definido de perguntas;
– Entrevistas abertas: sem agenda pré-definida; se adapta para
explorar o conhecimento do stakeholder.
27/09/2021 63
Obtendo os requisitos
• Técnicas para levantamento de requisitos:os(Pontos de
vista)
– Cenários
– Casos de Uso
– Etnografia
27/09/2021 64
Cenários
• Descreve uma situação de uso do sistema;
• Inclui informações como:
– Nome do Cenário;
– Ator;
– Pré-condição;
– Fluxo normal;
– Fluxos alternativos;
– Pós-condição.
27/09/2021 65
Exemplo
• Nome do Cenário: Sacar dinheiro
• Ator: Correntista
• Pré-condição: Conta e senha validada
• Fluxo normal:
– Entrar com valor do saque
– Confirmar dados e operação
– Debitar valor da conta do cliente
• Fluxos alternativo: Saldo insuficiente
– Apresentar aviso ao cliente
• Pós-condição:
– Valor sacado é debitado do saldo do cliente
27/09/2021 66
Obtendo os requisitos
• Técnicas para levantamento de requisitos:
– Cenários
– Casos de Uso
– Etnografia
27/09/2021 67
Casos de Uso
• Introduzida inicialmente no método Objectory(JACOBSON et
al., 1993).
• Em sua forma mais simples, identificam:
– Os atores envolvidos;
– As funcionalidades principais;
– A interação entre atores e funcionalidades do sistema.
27/09/2021 68
Casos de Uso
27/09/2021 69
Obtendo os requisitos
• Técnicas para levantamento de requisitos:
– Cenários
– Casos de Uso
– Etnografia
27/09/2021 70
Etnografia
• É uma técnica de observação utilizada para compreender os
processos operacionais;
• O analista (engenheiro de requisitos) se insere na
organização do cliente:
– Observa o trabalho no dia a dia;
– Anota as tarefas dos funcionários.
27/09/2021 71
Etnografia
• É eficaz para descobrir:
– maneira como as pessoas realmente trabalham;
– da cooperação e conscientização das atividades de outras pessoas;
• Desenvolver um protótipo;
• Revelar detalhes importantes que são ignorados por outras
técnicas.
27/09/2021 72
Validação de Requisitos
• Demonstrar se os requisitos definem o sistema que o cliente realmente
quer.
• Os diferentes tipos de validação que devem ser efetuados:
• Validade
– O sistema fornece as funções que melhor atendem às necessidades do cliente?
• Consistência
– Existe algum conflito de requisitos?
• Completude
– Estão incluídas todas as funções e restrições requeridas pelo cliente ?
27/09/2021 73
Validação de Requisitos
• Realismo
– Os requisitos podem ser implementados com o orçamento e a tecnologia
disponíveis?
• Verificabilidade
– Os requisitos podem ser verificados? Pode ser escrito um conjunto de testes
que demonstrem que o sistema atende a cada requisitos especificado.
27/09/2021 74
Validação de Requisitos
• Técnicas de Validação de Requisitos:
• Revisões de requisitos
– Análise manual sistemática dos requisitos.
• Prototipação
– Usando um modelo executável do sistema para verificar os
requisitos.
• Geração de casos de teste
– Desenvolvimento de testes para verificar os requisitos
implementados.
27/09/2021 75
Documentos de requisitos de
software
• Algumas vezes chamado de especificação de
requisitos de software ou SRS (Software
Requirements Specification);
• É a declaração oficial do que os desenvolvedores
de sistema devem implementar;
• Deve incluir os requisitos de usuário de um sistema
e uma especificação detalhada dos requisitos de
sistema.
• Se houver um grande número de requisitos, os
requisitos detalhados de sistema podem ser
apresentados em um documento separado.
27/09/2021 76
Documentos de requisitos de
software
• A figura 6.5 ilustra os possíveis usuários do
documento e como eles o utilizam.
27/09/2021 77
Documentos de requisitos de
software
27/09/2021 78
Documentos de requisitos de
software
27/09/2021 79
• Formato sugerido pelo padrão IEEE
Gerenciamento de Requisitos
• Usuários muitas vezes mudam os requisitos ou “não
sabem o que querem”...
• Requisitos são, inevitavelmente, incompletos e
inconsistentes:
– Novos requisitos surgem durante o processo, à medida que as
necessidades de negócio mudam e uma melhor compreensão
do sistema é desenvolvida;
– Os diferentes pontos de vista têm requisitos diferentes e estes
são frequentemente contraditórios.
27/09/2021 80
Gerenciamento de Requisitos
• É o processo de gerenciamento de mudanças de requisitos
durante o processo de engenharia de requisitos e o
desenvolvimento de sistema.
• É necessário:
– Compreender e controlar as mudanças dos requisitos;
– Avaliar os impactos das mudanças;
27/09/2021 81
Gerenciamento de Requisitos
• Fatores para a mudança de requisitos
– Erros e inconsistência de requisitos
– Evolução do conhecimento sobre o sistema
– Problemas técnicos, de custo e prazo
– Mudança de prioridades
– Mudanças organizacionais
27/09/2021 82
Planejamento de
gerenciamento de requisitos
• Durante o processo de gerenciamento de requisitos, você tem
de planejar:
– A Identificação de requisitos
• Como os requisitos são identificados individualmente;
– O processo de gerenciamento de mudanças
• Avalia o impacto e o custo das mudanças;
– Políticas de rastreabilidade
• É a quantidade de informações sobre os relacionamentos de
requisitos;
– Ferramenta de apoio
• O apoio de ferramenta requisitada para auxiliar no
gerenciamento das mudanças de requisitos.
27/09/2021 83
Conclusão
• A engenharia de requisitos define, sem dúvida, um dos mais
importantes conjuntos de atividades a serem realizadas em
projetos de desenvolvimento de software.
• Embora não garanta a qualidade dos produtos gerados, é
um pré-requisitos básico para que obtenhamos sucesso no
desenvolvimento do projeto.
27/09/2021 84
Dúvidas???
27/09/202
1
85