Processo de Eng. Requisitos
p Composto por quatro (ou cinco) atividades
de alto nível (Soares, 2005):
p Viabilidade
p Identificação.
p Análise e negociação.
p Especificação e documentação. p Validação.
Viabilidade
p interação com "as partes interessadas" (ou stakeholder em
inglês) do projeto
p reuniões ou entrevistas
p Será que o sistema contribui para os objetivos da
organização?
p Dadas as restrições tecnológicas, organizacionais
(econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado?
p Se o novo sistema não fosse implementado, quais seriam
as alternativas para a organização?
p Quais são os problemas que os sistemas atuais apresentam
e como é que um sistema novo irá resolver estas falhas?
p Caso haja necessidade de integração entre diferentes
Identificação
p Compreensão do domínio:
p Identificação das partes interessadas: p Captura:
n consiste na obtenção com o cliente dos
requisitos (funcionais e não-funcionais) pretendidos para o sistema.
p Identificação e análise de problemas:
n os problemas devem ser identificados (e a sua
definição deve ser consensual) e
n devem ser propostas soluções em conjunto
Técnicas para levantamento de
requisitos
p Entrevista e Questionários p Workshop de requisitos p Cenários p Prototipagemn Versão inicial do sistema com poucos
Análise e negociação dos requisitos
p Classificação:
n agrupamento de requisitos em "módulos"
p Resolução de conflitos p Prioritização:
n consiste na atribuição de uma "prioridade" a cada
requisito (por exemplo elevada/média/baixa); p Confirmação:
n Confirma com as partes interessadas n a completude dos requisitos,
Especificação e documentação
p Requisitos Funcionais
Validação
p demonstrar que o documento de
requisitos produzido corresponde, de fato, ao sistema que o cliente pretende
Trecho do Pequeno Príncipe: Antoine Saint-Exupéry, 1996.
“E ele repetiu-me então, brandamente, como uma coisa muito séria: - Por favor ... desenha-me um carneiro ...
Quando o mistério é muito impressionante, a gente não ousa desobedecer. Por mais absurdo que aquilo me parecesse a mil milhas de todos os lugares habitados e em perigo de morte, tirei do bolso uma folha de papel e uma caneta. Mas lembrei-me, então, que eu havia estudado de preferência geografia, história, cálculo e gramática, e disse ao garoto (com um pouco de mau humor) que eu não sabia desenhar. Respondeu-me:
-Não tem importância. Desenha-me um carneiro.
Como jamais houvesse desenhado um carneiro, refiz para ele um dos dois únicos desenhos que sabia. O da jibóia fechada. E fiquei estupefato de ouvir o garoto replicar:
Engenharia de Requisitos / An
- Não! Não! Eu não quero um elefante numa jibóia. A jibóia é perigosa e o elefante toma muito espaço. Tudo é pequeno onde eu moro. Preciso é dum carneiro. Desenha-me um carneiro.
Então eu desenhei.
Olhou atentamente, e disse:
- Não! Esse já está muito doente. Desenha outro. Desenhei de novo.
-Bem vês que isto não é um carneiro. É um bode... Olha os chifres... -Fiz mais uma vez o desenho.
Mas ele foi recusado como os precedentes: - Este aí é muito velho. Quero um carneiro que viva muito.
-Então, perdendo a paciência, como tinha pressa de desmontar o motor, rabisquei o desenho ao lado.
E arrisquei:
-Esta é a caixa. O carneiro está dentro.
Mas fiquei surpreso de ver iluminar-se a face do meu pequeno juiz: - Era assim mesmo que eu queria! Será preciso muito capim para esse carneiro?”
Engenharia de Requisitos / An
Definindo
Definindo o o SucessoSucesso do Software do Software
p Clientes satisfeitos p Eles estão satisfeitos quando você: n Atende às expectativas n Entrega no prazo n Entrega no orçamento O
O SucessoSucesso comecomeççaa comcom a Gerência de Requisitos
a Gerência de Requisitos
Engenharia de Requisitos / An
Principais
Principais FatoresFatores de de FalhaFalha dos Projetosdos Projetos
o
o Objetivos Objetivos nãonão estavamestavam clarosclaros o
o FaltaFaltade de ““InputInput”” do do UsuUsuááriorio o
o FaltaFaltade de suportesuportedo do nníívelvel executivoexecutivo o
o Ignorar um grupo de clientesI
o
o Omitir um grupo de requisitosO o
o Permitir inconsistências entre grupos de requisitosP o
o Aceitar um requisito ambíguo e inconsistenteA o
o Aceitar requisito inadequado, incorreto, indefinido, ou imprecisoA o
o Requisitos e Requisitos e especificaespecificaççõesões incompletosincompletos o
o Requisitos e Requisitos e especificaespecificaççõesõesinstinstááveisveis ((mudanmudanççasas))
Engenharia de Requisitos / An
Como os Projetos
Como os Projetos podempodem terter sucessosucesso??
p Análise do Problema
n Entenda o problema
n Obtenha concordância dos envolvidos
p Levantamento dos Requisitos
n Identifique quem usará o sistema (atores)
n Descubra como o sistema será usado (casos de uso)
p Gerência de Requisitos
n Especifique os requisitos completamente n Gerencie expectativas, mudanças e erros n Controle o aumento do escopo
n Defina a equipe e a mantenha informada
p Análise do Problema
n Entenda o problema
n Obtenha concordância dos envolvidos
p Levantamento dos Requisitos
n Identifique quem usará o sistema (atores)
n Descubra como o sistema será usado (casos de uso)
p Gerência de Requisitos
n Especifique os requisitos completamente
n Gerencie expectativas, mudanças e erros
n Controle o aumento do escopo
n Defina a equipe e a mantenha informada
Engenharia de Requisitos / An
Mas o que são Requisitos?
Mas o que são Requisitos?
p Os requisitos de um sistema de
computação constituem uma
especificação das características e propriedades do sistema ou
p Uma descrição do que o sistema
deve fazer, de como ele deve se comportar, bem como das suas restrições de operação.
Engenharia de Requisitos / An
Mas o que são Requisitos?
Mas o que são Requisitos?
p É importante ressaltar que os requisitos
descrevem "o que o sistema deve
fazer"- e também "o que ele não deve fazer"- sem dizer "o como fazer".
p Quando o requisito é expresso em
termos do comportamento do sistema, este comportamento deve ser possível de ser percebido por um observador externo ao sistema.
Engenharia de Requisitos / An
O que são requisitos?
O que são requisitos? Clientes Necessidades Usuários Limitações Impossibilidades Infra-Estrutura Tecnológica Engenharia de Requisitos / An
Requisitos e Especifica
Requisitos e Especificaççãoão
p Requisito (IEEE)
n Uma condição ou capacidade necessitada por
um usuário para resolver um problema ou alcançar um objetivo
n Uma condição ou capacidade que deve ser
satisfeita por um sistema para satisfazer um contrato ou um padrão
p Especificação:
n descrição rigorosa e minuciosa das
características que um material, uma obra, ou um serviço deverá apresentar
n processo de representação dos requisitos de
uma forma que leva à implementação bem-sucedida
Engenharia de Requisitos / An
p Uma compreensão completa dos
Requisitos do Software é fundamental
para obter um software e um processo de desenvolvimento com alta qualidade
p Não importa quão bem projetado ou
codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao
desenvolvedor
Importância da Especifica
Importância da Especificaçção Corretaão Correta
Engenharia de Requisitos / An
p
ser a base para o desenvolvimento;
p
permitir o controle da qualidade do
produto;
p
estabelecer a comunicação entre o pessoal
envolvido no projeto;
p
auxiliar no entendimento do problema.
Especifica
Especificaçção de Requisitosão de Requisitos
Engenharia de Requisitos / An
Fase de An
Fase de Anáálise de Requisitoslise de Requisitos
ANÁLISE DE REQUISITOS Engenharia de Sistemas de Computador Projeto de Software
Escopo do Software •Primeiro passo técnico •Analista de Sistemas
PONTE
Engenharia de Requisitos / An
Conceito de Requisito
Requisito é uma condição ou capacidade • necessária para um usuário resolver
um problema ou alcançar um objetivo; • para satisfazer uma especificação
em um sistema ou em um componente; • com uma representação documentada.
Em: The IEEE Standard Glossary of Software Engineering Terminology, 1997.
Roc c o , 2 0 0 4 Engenharia de Requisitos / An
Fase de An
Fase de Anáálise de Requisitoslise de Requisitos
ANÁLISE DE REQUISITOS Engenharia de Sistemas de Computador Projeto de Software
Escopo do Software •Primeiro passo técnico •Analista de Sistemas
PONTE
Engenharia de Requisitos / An
Engenharia de Requisitos / An
Requisitos de Software
Requisitos de Software
p A Norma ISO/IEC 9126 define seis características de
qualidade de software que devem ser avaliados: n Funcionalidade (finalidade do produto)
n Usabilidade (esforço para utilizar, aprender o produto) n Confiabilidade (freqüência de falhas, recuperabilidade) n Eficiência (desempenho)
n Manutenibilidade (esforço necessário para modificar) n Portabilidade (capacidade de transferir o produto para
outros ambientes)
Engenharia de Requisitos / An
Como os Projetos Podem
Como os Projetos Podem TerTer SucessoSucesso??
p Análise do Problema
n Entenda o problema
n Obtenha concordância dos envolvidos
p Levantamento dos Requisitos
n Identifique quem usará o sistema (atores)
n Descubra como o sistema será usado (casos de uso)
p Gerência de Requisitos
n Especifique os requisitos completamente n Gerencie expectativas, mudanças e erros n Controle o aumento do escopo
n Defina a equipe e a mantenha informada
p Análise do Problema
n Entenda o problema
n Obtenha concordância dos envolvidos
p Levantamento dos Requisitos
n Identifique quem usará o sistema (atores)
n Descubra como o sistema será usado (casos de uso)
p Gerência de Requisitos
n Especifique os requisitos completamente n Gerencie expectativas, mudanças e erros n Controle o aumento do escopo
Gerência de Requisitos
Gerência de Requisitos
Atividades de:
- acompanhar o desenvolvimento
- controlar as mudanças dos requisitos Ações:
- planejamento desenvolvimento (“baseline”)
- rastreabilidade com componentes de software - definição do estado e avaliação da qualidade
- análise impacto e controle versões de mudanças
Roc c o , 2 0 0 4
Necessidades da
Necessidades da ElicitaElicitaççãoão p
p FazFaz Coleta de Fatos
p
p FazFaz Identificação de Fontes de Informação
p
p FazFaz Comunicação
p
p Faz/UsaFaz/Usa Ferramentas
p
p UsaUsa Pessoal
p
p UsaUsa Métodos
p
Identifica
Identificaçção das Fontes de Informaão das Fontes de Informaççãoão p O que são Stakeholders do
sistema?
n Qualquer pessoa afetada de
alguma forma pelo sistema
(atores, cliente, usuário final, desenvolvedor)
o A análise dos Stakeholders ajuda a
determinar o impacto que um novo sistema de informação terá.
Coleta de Fatos
Coleta de Fatos
p Entrevistas
p Coleta e Leitura de documentos
p Observação
p Questionários
p Análise de Protocolos
p Enfoque antropológico (estudo do ser humano)
p Reuniões
p Reutilização
Caracter
Caracteríísticas das Tsticas das Téécnicascnicas
p Brainstorm
n útil no início do processo levantamento de requisitos n reunião conjunta
n objetivo estimular a imaginação e a geração de idéias n não avalia um conjunto de soluções
p Entrevistas
n não-estruturadas n estruturadas
JAD
JAD -- JointJoint Application Application DevelopmentDevelopment
INTRODUZ TEMA MOSTRAR EXEMPLOS DISCUSSÃO CONSENSO DOCUMENTAÇÃO PENDÊNCIA IMPASSE Responsável Gerência Processo Processo p Usuários e desenvolvedores
trabalham juntos em uma reunião com o objetivo de:
n identificar o problema
n propor elementos de solução n negociar diferentes abordagens
n especificar um conjunto preliminar de
requisitos de solução
p Envolve:
n preparação para reunião a partir de
uma requisição geral do produto
Linguagem
Linguagem
p A linguagem é reflexo da cultura de uma
sociedade.
p Para entendermos algo de importante para uma
sociedade temos que entender sua linguagem.
p Deve-se compreender a linguagem antes de
elicitar as necessidades.
Exemplos
N
Níívelvel de de AbstraAbstraççãoão
p A comunicação pode ser ruidosa se os
indivíduos estiverem dialogando em diferentes níveis de abstração.
p Conflito presente entre generalistas e
especialistas.
Exemplo
Devemos conquistar mercados (Diretoria) X
Retroalimenta
Retroalimentaççãoão
p Obrigar ao receptor da informação a
recolocar a comunicação até que o emissor responda positivamente a recolocação.
p Resumir, parafrasear, confirmar.
? a