Aula III_Engenharia de Requisitos

Prévia do material em texto

UNIDADE I 
Engenharia de Requisitos de Software
3
Conteúdo Programático
§ Módulo I - Introdução
ü Engenharia de Requisitos (Conceitos Gerais).
§ Módulo II - Introdução
ü Tipos de Requisitos.
v Requisitos do Cliente x Requisitos do Produto.
v Qualidade de Requisitos.
ü Visões para Requisitos.
4
Conteúdo Programático
§ Módulo III – Elicitação de Requisitos
ü OAmbiente das Organizações.
ü Relacionamento entre Técnicos e Usuários,
ü Elicitação de Requisitos.
v Técnicas de Levantamento (Entrevistas, Brainstorming,
Questionários, Workshop de Requisitos, Etnografia, Jogo de
Funções, Prototipação, Casos de Uso e Cenários).
ü JAD – Joint Application Development.
5
Módulo I –
Requisitos de Sistemas
§ Definições
ü Para Pfleeger (2004), um requisito é uma característica do sistema
ou a descrição de algo que o sistema é capaz de realizar para atingir
os seus objetivos.
ü Para Sommerville (2008), as descrições das funções e restrições
são os requisitos do sistema.
ü No SWEBOK (2004), um requisito é descrito como uma
propriedade que o software deve exibir para resolver algum
problema no mundo real.
6
Requisitos de Sistemas
§ Um requisito é (IEEE Software Engineering Standards,
1987):
ü Uma condição ou capacidade necessária para um usuário resolver um
problema ou alcançar um objetivo.
ü Uma condição ou uma capacidade que deve ser alcançada ou estar
presente em um sistema para satisfazer um contrato, padrão,
especificação ou outro documento formalmente imposto...
7
Importância dos Requisitos
§ Estudo feito pelo Standish Group em 2010 (Pfleeger, 2012):
ü 350 companhias e 8.000 projetos de software.
ü Resultados:
v 31% dos projetos cancelados antes de estarem completos.
v Em pequenas companhias, somente 16% dos projetos foram entregues
no prazo e no orçamento inicialmente estabelecidos.
v Em grandes companhias, apenas 9% atenderam esses critérios.
8
Algumas Estatísticas
§ Standish Group descreveu 3 categorias de projetos:
ü Sucesso (16.2%) - Cobre todas as funcionalidades em tempo e dentro do
custo previsto.
ü Problemático (52.7%) - Não cobre todas as funcionalidades exigidas, custo
aumentado e está atrasado.
ü Fracasso (31.1%) - Cancelado durante o desenvolvimento.
9
Causas para os Projetos Falhos – Standish Group
10
Custos gerados por problemas em requisitos
§ Segundo Boehm e Papaccio (Pfleeger, 2012), o custo relativo
para o conserto de um problema de requisitos em cada fase de
desenvolvimento de sistema é:
ü $1 na fase de análise de requisitos.
ü $5 na fase de projeto do sistema.
ü $10 na fase de codificação.
ü $20 na fase de teste de unidade.
ü $200 após a entrega do sistema.
11
Cenário Atual de Desenvolvimento
§ Outros custos não facilmente mensuráveis:
§ Os erros mais caros são aqueles cometidos no processo de requisitos e
descobertos pelo usuário!
ü perda de oportunidades.
ü perda da confiança de clientes.
ü perda de clientes.
ü correção do erro.
12
Requisitos e Análise de Sistemas
§ Maiores Desafios no Desenvolvimento de Sistemas:
ü Compreensão do domínio do problema.
ü Comunicação efetiva com reais usuários do sistema.
ü Evolução contínua dos requisitos do sistema.
13
Importância dos Requisitos
§ Uma especificação de requisitos é importante por que:
ü Estabelece uma base de concordância entre o cliente e o fornecedor sobre
o que o software fará.
ü Fornece uma referência para a validação do produto final.
ü Uma especificação de requisitos de alta qualidade é pré-requisito para
um software de alta qualidade.
ü Reduz o custo de desenvolvimento.
14
Porque é difícil?
Ø Fonte: Steve – Easterbrook.
§ Problemas tem fronteiras mal definidas ( abertos).
§ Requisitos estão no contexto organizacional (inclinados a conflitos).
§ Soluções para os problemas da análise são artificiais.
§ Problemas são dinâmicos.
§ Requer conhecimento interdisciplinar e habilidades específicas.
15
Engenharia de Requisitos – Visão Geral
16
Conceitos de Engenharia de Requisitos
§ O Desenvolvimento de Requisitos cria e interpreta os requisitos.
§ AGerência de Requisitos organiza e mantém registro dos mesmos.
17
Engenharia de Requisitos
§ Objetivos:
ü estabelecer uma visão comum entre o cliente e a equipe de
projeto em relação aos requisitos que serão atendidos pelo
projeto de software.
ü registrar e acompanhar requisitos ao longo de todo o
processo de desenvolvimento.
§ Metas:
ü 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.
18
Mas o que acontece se... reflexões
§ o usuário mudar de ideia em relação a uma funcionalidade?
§ o ambiente mudar?
§ o usuário perceber novas possibilidades na automação?
§ o engenheiro de requisitos (ou analista) não entendeu corretamente a
necessidade do usuário?
19
Atividades da Engenharia de Requisitos com Foco 
no Usuário
§ Identificar Objetivos de Negócio
ü Por que desenvolver algo?
§ Identificar Stakeholders (Interessados)
ü Quem está envolvido.
§ Obter diferentes pontos de vista
ü Com que os stakeholders estão preocupados?
ü Existem conflitos?
§ Resolver Conflitos (caso existam)
§ Identificar Cenários
ü Quais resultados as pessoas desejam?
20
Elicitação de Requisitos
§ Problemas comuns na elicitação de requisitos:
ü Problemas de escopo
v O limite do sistema é mal definido, ou detalhes técnicos
desnecessários confundem os objetivos globais.
ü Problemas de entendimento
v Os clientes/usuários não estão completamente certos do que
é necessário, não tem pleno entendimento do domínio do
problema, têm dificuldade de comunicar as necessidades,
têm pouca compreensão das capacidades.
ü Problemas de volatilidade
v Os requisitos mudam com o tempo.
21
Desafios no processo de elicitação de requisitos
§ Falta de conhecimento do desenvolvedor do
domínio do problema
ü Usuário com vaga noção do que precisa e do que um produto
de software pode oferecer.
§ Falta de conhecimento do usuário das suas reais
necessidades
ü Desenvolvedor sem conhecimento adequado do domínio, o
que leva a decisões erradas.
22
Desafios no processo de elicitação de requisitos
§ Comunicação inadequada entre os
desenvolvedores e usuários
ü Desenvolvedor não ouve o que os usuários têm a dizer e
força suas próprias visões e interpretações.
§ Domínio do processo de elicitação de requisitos
pelos desenvolvedores
ü Usuários incapazes de expressar suas necessidades
apropriadamente.
ü Significados diferentes a termos comuns.
23
Desafios no processo de elicitação de requisitos
§ Problemas de comportamento
ü Falta de entendimento sobre as consequências das decisões
ou as alternativas possíveis.
§ Dificuldade do usuário tomar decisões
ü A elicitação de requisitos é um processo social.
ü Conflitos e ambiguidades nos papeis que os usuários e
desenvolvedores desempenham.
§ Questões técnicas
ü Complexidade crescente dos sistemas atuais.
24
Desafios no processo de elicitação de requisitos
ü Relatos de experiências são bem-vindos!
§ Outros
25
Módulo II – Tipos de Requisitos
§ Requisitos Funcionais.
§ Requisitos Não Funcionais.
§ Requisitos do Domínio.
26
Requisitos Funcionais
§ Requisitos diretamente ligados a funcionalidade
do software, descrevem as funções que o software
deve executar.
§ Um requisito funcional descreve uma interação
entre o sistema e seu ambiente.
§ Exemplo: “O sistema deve permitir que o
administrador emita um relatório com os
resultados dos testes clínicos de um paciente.”
27
Requisitos Funcionais
§ [RF001] O software deve permitir que o gerente
pesquise os dados cadastrais de um cliente.
§ [RF002] O software deve permitir que usuários
visualizem documentos cadastrados.
28
Exercícios
§ Forneça 3 exemplos de Requisitos Funcionais
para:
ü Sistema de Studio Fitness (Pilates, Yoga e Treinamento Funcional);
ü Sistema Hospitalar;
ü Sistema de Pet Shopping.
29
Requisitos Não Funcionais
§ São requisitos que expressamcondições que o
software deve atender ou qualidades específicas
que o software deve ter.
§ Em vez de informar o que o sistema fará, os
requisitos não-funcionais colocam restrições no
sistema.
§ Exemplo: “As consultas ao sistema devem ser
respondidas em menos de três segundos.”
30
Requisitos Não Funcionais
§ Definem propriedades e restrições do sistema (tempo, espaço, etc).
§ Requisitos de processo também podem especificar o uso de
determinadas linguagens de programação, método de
desenvolvimento.
§ Devido à sua própria definição, requisitos não-funcionais devem
ser mensuráveis.
§ Assim, deve-se associar forma de medida/referência a cada
requisito não funcional elicitado.
31
Classificação de Requisitos não Funcionais
§ Requisitos Externos
ü Produto deve comportar-se de forma particular (velocidade
de execução, confiabilidade, etc.)
§ Requisitos do Produto
ü Consequência de políticas e procedimentos organizacionais
(padrões de processo usados, requisitos de implementação,
etc.).
§ Requisitos Organizacionais
ü Consequência de fatores externos ao sistema e ao processo
de desenvolvimento (legislação, etc.)
32
Classificação de Requisitos não Funcionais
o Requisitos de Usabilidade
ü requisitos que especificam características desejáveis que um
sistema (sub-sistema) deve possuir.
ü incluem:
§ Requisitos do Produto
v e.g., usuários experientes devem ser capazes de
utilizar todas as funções do sistema após duas
horas de treinamento.
33
Classificação de Requisitos não Funcionais
o Requisitos de Confiabilidade
v e.g., usuários deve ser capazes de realizar operações sem
perda de dados.
o Requisitos de Segurança
o Requisitos de Desempenho
o Requisitos de Capacidade
v e.g., o acesso ao dados deve ser protegido.
v e.g., o sistema deve processar X requisições por segundo.
v e.g., o sistema deve suportar X usuários
concorrentemente.
o Requisitos de Portabilidade
v e.g., o sistema deve rodar nas plataformas X e Y.
34
Classificação de Requisitos não Funcionais
o Requisitos de Entrega
ü são procedentes de políticas e procedimentos nas
organizações do cliente e do desenvolvedor.
ü incluem:
§ Requisitos Organizacionais
v e.g., um relatório de progresso deve ser entregue a
cada duas semanas.
o Requisitos de Implementação
v e.g., o sistema deve ser implementado na
linguagem C++
35
Classificação de Requisitos não Funcionais
o Requisitos de padrões e métodos de
desenvolvimento
v e.g., uso de métodos orientados a objetos;
desenvolvimento utilizando a ferramenta X.
36
Classificação de Requisitos não Funcionais
o Requisitos de Interoperabilidade
ü requisitos impostos tanto ao produto quanto ao processo de
desenvolvimento em função do ambiente no qual o sistema é
desenvolvido
ü incluem:
§ Requisitos externos
v e.g., o sistema deve interagir com os sistemas X e
Y.
37
Classificação de Requisitos não Funcionais
o Restrições éticas
v e.g., o sistema não deverá revelar aos operadores
nenhuma informação pessoal dos clientes.
o Restrições Legais
v e.g., o sistema deverá armazenar as informações de
acordo com a lei número XXYY.ZZ.
38
39
Exercícios
§ Forneça 3 exemplos de Requisitos Não
Funcionais para cada tipo de requisitos não
funcional de produto para:
ü Sistema de Studio Fitness (Pilates, Yoga e Treinamento 
Funcional);
ü Sistema Hospitalar;
ü Sistema de Pet Shopping.
40
Requisitos de Domínio
§ Derivados do domínio da aplicação e descrevem
características do sistema e qualidades que
refletem o domínio.
§ Podem ser requisitos funcionais novos, restrições
sobre requisitos existentes ou computações
específicas.
§ Se requisitos de domínio não forem satisfeitos, o
sistema pode tornar-se não prático.
41
Problemas
§ Implicitude
ü Requisitos são descritos na linguagem do domínio da
aplicação.
ü Não é entendido pelos engenheiros de software que vão
desenvolver a aplicação.
§ Entendimento
ü Especialistas no domínio entendem a área tão bem que não
tornam todos os requisitos de domínio explícitos.
42
Requisitos de Domínio
ü A desaceleração do trem deve ser computada através da
fórmula:
Dtrem=Dcontrole+Dgradiente
§ Exemplos
43
Exercícios
§ Forneça 3 exemplos de requisitos de domínio
para:
ü Sistema de Studio Fitness (Pilates, Yoga e Treinamento 
Funcional);
ü Sistema Hospitalar;
ü Sistema de Pet Shopping.
44
Visões para Requisitos
§ Requisito = Declaração em alto nível ou
Definição detalhada?
ü 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 de sistema: estabelecem detalhadamente as funções 
e as restrições de sistema.
45
Possíveis Fontes de Requisitos
§ Entrevistas com usuários
§ Ambientes do sistema
§ Objetivos de negócio
§ Requisitos de mercado
§ Obrigações contratuais
§ Trabalho no ambiente do
usuário
§ Sistemas existentes ou análogos
§ Modificações propostas pelos
usuários.
§ Reuniões dos usuários.
§ Workshop.
§ Protótipos.
§ Estudos.
§ Questionários.
§ Consultores.
§ Observação.
46
Analisando fontes para os Requisitos de Sistemas
§ Funcionalidades
ü O que o sistema realizará?
ü Quando o sistema o fará?
ü Existem diversos modos de operação?
ü Como e quando o sistema deverá ser modificado ou
aperfeiçoado?
ü Existem restrições em relação ao tempo de execução ou
tempo de resposta?
47
Analisando fontes para os Requisitos de Sistemas
§ Interfaces
ü Os dados de entrada provêm de outros sistemas?
ü Os dados de saída são encaminhados para outros sistemas?
ü Há um modo pré-estabelecido no qual os dados devem ser
formatados?
§ Documentação
ü Que documentação é necessária?
ü Esta documentação deve ser on-line, em manual impresso ou
ambos?
ü A que público se destina cada tipo de documentação?
48
Analisando fontes para os Requisitos de Sistemas
§ Dados
ü Qual deverá ser o formato dos dados de entrada e de saída?
ü Qual a frequência que os dados serão recebidos ou
enviados?
ü Quão precisos esses dados devem ser?
ü Qual o fluxo de dados no sistema?
ü Qual o período de tempo de armazenamento para cada tipo
de dado?
49
Analisando fontes para os Requisitos de Sistemas
§ Recursos
ü Que materiais, pessoal e outros recursos necessários para
construir, usar e manter o sistema?
ü Que habilidades os desenvolvedores devem ter?
ü Qual o espaço físico necessário ao sistema?
ü Quais as necessidades para o ambiente físico de
desenvolvimento? E de produção?
ü Qual o limite de tempo para desenvolvimento?
ü Qual o limite de investimento nesse sistema?
50
Analisando fontes para os Requisitos de Sistemas
§ Segurança
ü Como o acesso ao sistema ou às suas informações devem ser
controladas?
ü Como os dados de um usuário serão isolados dos dados de
outros?
ü Qual a política de backup a ser adotada para o sistema?
ü As cópias de segurança devem ser armazenadas em locais
diferentes?
ü Quais as precauções em relação a situações de emergência
ou catástrofe (incêndio, roubo, ...)?
51
Analisando fontes para os Requisitos de Sistemas
§ Garantia da Qualidade
ü Quais os requisitos em relação à confiabilidade,
disponibilidade, manutenibilidade, ...?
ü O sistema deve detectar falhas /erros?
ü Qual o tempo esperado entre falhas?
ü Existe um tempo máximo para reinicialização do sistema
após uma falha?
ü Como o sistema pode incorporar mudanças ao seu projeto?
ü A manutenção será apenas corretiva ou incluirá também
manutenção adaptativa /perfectiva?
52
Atores do Processo de Requisitos
§ Exemplos típicos de Stakeholders
ü Usuários: grupo que irá usar o software.
ü Clientes: grupo que encomendou o software ou que
representa o público alvo do mesmo.
ü Analistas de mercado: para casos de produtos que precisam
da análise de mercado.
ü Autoridades de regulamentação: para aplicações com
regulamentações próprias, como transporte público.
ü Desenvolvedor/Engenheiro de Software
ü Outros engenheiros de software: em casos como reuso de
componentes.
53
Atores do Processo de Requisitos
§ O contato inicialnormalmente indica pessoas com quem se deve
falar, seus papéis e seus interesses.
§ Stakeholders incluem usuários diretos do sistema e interessados
indiretos também.
§ Stakeholders podem sugerir outras pessoas que devem ser
consultadas …
54
Diferenças de Visão: Desenvolvedores x Usuários 
(Pfleeger, 2004)
55
§ SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo Pearson Addison Wesley,
2008. 552 p. ISBN 9788588639287. Capítulo VI e VII.
§ ENGHOLM. H. J. Engenharia de Software na prática. Editora Novatec. 2010 – Capítulo IV
e VIII.
§ PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. 2. ed. São Paulo:
Pearson Prentice Hall, 2007. 537 p. ISBN 9788587918314. Capítulo IV.
§ Notas de aula Profa. Judith Pavón –UAM.
§ Notas de aula Professor Marcos Kalinowski.
Referências