Engenharia de Requisitos Silvia Regina Vergilio - UFPR.
-
Upload
joaovictor-corte -
Category
Documents
-
view
224 -
download
2
Transcript of Engenharia de Requisitos Silvia Regina Vergilio - UFPR.
Engenharia de Requisitos
Silvia Regina Vergilio - UFPR
1) Objetivos O escopo do projeto é refinado em detalhe e
será produzida uma especialização de requisitos.
Objetivos Fornecer traduzida Projeto, dados informação procedimentos, representações para arquitetura
1) Objetivos – Aspecto Fundamental Comunicação com o Uusário
“Eu sei que você acredita ter entendido o que você pensa que eu disse, mas não estou certo se você está ciente de que o que você ouviu não é o que eu
queria dizer.”
Cliente anônimo.
1) Objetivos - Documentos Gerados Especificação de Requisitos de Software
Manual Preliminar do Usuário
Plano de Projeto do Software (revisto).
2) Requisitos Requisito: condição necessária para
a obtenção de certo objetivo ou para o preenchimento de certo fim
Requisito de software: requisitos que o produto a ser desenvolvido deve possuir
2) Requisitos Requisitos funcionais: funcionalidade, o
que o software deve fazer Requisitos não funcionais: confiabilidade
(disponibilidade, integridade, segurança), acurácia, desempenho, interface HM, portabilidade, etc.
Requisitos de desenvolvimento e manutenção, procedimentos de controle e qualidade
3) Engenharia de Requisitos Passos: Entendimento do domínio de
aplicação Extração de requisitos: classificação e
organização Análise/Especificação dos requisitos –
modelos Validação – necessidades do usuário
3.1) Extração de Requisitos Processo de transformação das
idéias que estão na mente do usuário (entradas) em um documento formal (saída).
3.1) Extração de Requisitos – Dificuldades Para conseguir informação pertinente. Para lidar com a complexidade. (Tornar o
problema manipulável; detectar omissões, inconsistências )
Para acomodar mudanças. (Coordenar, avaliar impacto; corrigir defeitos sem gerar erros)
3.1) Extração de Requisitos – Principais Causas 1. Deficiências na comunicação 2. Técnicas e ferramentas inadequadas 3. Desconsideração de alternativas.
É necessário aplicar: -princípios fundamentais -métodos/técnicas sistemáticos
3.1) Extração de Requisitos – O Analista Absorver fatos a partir de fontes
conflitantes ou confusas. Entender os ambientes do usuário/cliente. Comunicamos bem na forma verbal e
escrita. “ Enxergar a floresta apesar das árvores”
3.1) Extração de Requisitos – Tarefas 1. Reconhecimento (identificação do
problema ) 2. Avaliação do problema e síntese de
soluções gerais + critérios de validação. 3. Representação dos requisitos => software 4. Revisão da especificação reexame do
Plano de Projeto de Software.
3.1) Extração de Requisitos – Quem participa desenvolvedor
pessoal de apoio e documentação
usuários ou potenciais usuários
outras fontes de informações: pessoas e documentos
3.1) Extração de Requisitos – Procedimentos Genéricos Perguntar – identificar o usuário Observar e inferir – comportamento do
usuário, inferir suas necessidades Negociar a partir de um conjunto padrão de
requisitos Estudar e identificar problemas Supor – se o produto é novo comparar com
existentes
3.1) Técnicas de Extração de Requisitos - Entrevistas Identificar candidatos
Preparação para entrevista agendar preparar questões
Condução da entrevista
3.1) Técnicas de Extração de Requisitos - Entrevistas Condução da entrevista
apresentação e objetivos esperar respostas incompletas repetir frases do entrevistado com
suas próprias palavras perguntas do tipo sim/não – dúvidas não se perder em detalhes o entrevistado precisa ter o contexto
3.1) Técnicas de Extração de Requisitos - Entrevistas Finalização tempo, resposta à todas as perguntas consolidar informações (5min),
agradecimentos
Geração de um documento escrito, planejar próximos passos
3.1) Técnicas de Extração de Requisitos - Braimstorming Técnica para geração de idéias Reuniões entre desenvolvedores e
usuários Um líder é necessário Geração e consolidação das idéias Ausência de crítica e julgamento Elimina dificuldades de comunicação
3.1) Técnicas de Extração de Requisitos - PIECES Geralmente é aplicada na análise
de produtos já existentes, mas pode ser adaptada
Fornece um conjunto de categorias de questões e de problemas para o desenvolvedor extrair os requisitos
3.1) Técnicas de Extração de Requisitos - PIECESSeis categorias:P - desempenhoI - informaçãoE - economiaC - controleE - eficiênciaS - serviços
3.1) Técnicas de Extração de Requisitos - JAD
JAD – Joint Application Design Princípios básicos:
dinâmica de grupo uso de técnicas visuais manutenção do processo organizado
e racional utilização de documentação padrão
Etapas: planejamento e projeto
3.1) Técnicas de Extração de Requisitos - JAD
Seis tipos de participantes líder engenheiro de requisitos executor representantes do usuário representantes de produtos de sw especialista
3.1) Técnicas de Extração de Requisitos - JAD
Sessão
Um ou maisEncontrosrequisitosdesenvolvidos
edocumentados
Adaptação
Preparar OrganizarEquipe e Material
Finalização
Converte a informaçãofinal em umdocumento
3.1) Técnicas de Extração de Requisitos - Prototipação1. Determinar se o software é um bom candidato
Áreas de aplicação : interface, . . . Complexidade : desenvolvimento de muito código
inviabiliza a prototipação (particionável) Característica do cliente e gerente
2. Representação Resumida de Requisitos => particionamento .
3. Um projeto rápido ( arquitetura e dados ).
3.1) Técnicas de Extração de Requisitos - Prototipação4. Protótipo é criado e testado.
Técnicas de quarta geração Reutilização de Software Ferramentas de Videoconferência Especialização formal + ambientes interativos.
5. Teste pelo usuário - sugestões (+importante).
6. Repetição de 4 e 5 até que todos os requisitos sejam formalizados; ou que o protótipo tenha evoluído.
4) Modelos para Especificação Representam a realidade Ajudam a organização e especificação
mas não na extração Utilizam os princípios de abstração e
decomposição – lidar com complexidade
Existem diferentes tipos de especificação ao longo do desenvolvimento e em vários níveis.
4) Especificação pode ser Especificação dos requisitos –
cliente e desenvolvedor Especificação de projeto geral –
projetista e implementador Especificação de módulos –
programadores que utilizam e implementam os módulos
4) Princípios- Especificação Separar funcionalidade de
implementação Deve abranger o sistema do qual o
sw é um componente Deve ser operacional (utilizável) Tolerante a incompleteza Consistente
4) Princípios - Especificação Realista
Fracamente acoplada e localizada localizada: para que um único
elemento tenha que ser modificado fracamente acoplada: permitir que
adições e remoções sejam feitas facilmente
4) Modelos para Especificação Permitem a aplicação dos
princípios de ES. Geralmente cobrem três dimensões
do sistema dados (que dados ele mantém) funções (o que o sistema faz) comportamento (como ele se
comporta – estados e eventos)
5) Diagrama de Fluxo de Dados – Modelo de Função
5) Diagrama de Fluxo de Dados – Modelo de Função
O DFD é um modelo que nos permite mostrar como a informação (dados) flui através de um sistema (ou seja, como ela vai sendo transformada ou organizada) são recebidos podem ser armazenados podem fluir de um processo a outro podem ser transferidos para o ambiente
externo
5) Diagrama de Fluxo de Dados – Modelo de Função
______
5) Diagrama de Fluxo de Dados (DFD) - Exemplo
Agente de
Viagem
Sistema de
Reserva
Sistema de
Cobrança
Preparação de
Bilhete
Cliente
Horário, dia, destino
Dados do vôo
Custo
Bilhete
Conta
Dados contábeis
Diretórios de vôo
Arquivo de Contabilidade
Informação sem vôos
5) Diagrama de Fluxo de Dados (DFD) – Como construir
5) Diagrama de Fluxo de Dados (DFD) – Como construir
5) Diagrama de Fluxo de Dados (DFD) – Como construir Particionar as funções em sub-
funções: uma bolha deve ser particionada por
vez rótulos dos fluxos, bolhas e arquivos
devem ser significativos a continuidade da informação deve
ser mantida
5) Diagrama de Fluxo de Dados (DFD) – Como construir
F
f4
A B
A
x
y
z
B
z
x
y
5) Diagrama de Fluxo de Dados (DFD) – Quando parar O DFD mostra as transformações de
todas as entrada em saídas Os sub-processos não particionados
podem ser considerados elementares
Cada bolha está conectada corretamente ao resto da rede
As conexões foram minimizadas
5) Diagrama de Fluxo de Dados (DFD) O DFD não mostra: descrição dos fluxos nem mecanismos de
sincoronização comportamento
5) Diagrama de Fluxo de Dados – Extensão Tempo Real
Fluxo de dados que não é contínuo temp - max temp - medida.
Transforma controle ou eventos.
Representa eventos.
Armazena itens de controle ou eventos.
5) Diagrama de Fluxo de Dados – Extensão Tempo Real
Monitora ph
Mantém ph
constante
Muda ph
Processo de
Controle
Inicia
Pára
Ativa/Desativa
ph no nível desejado
Controle da Válvula de entrada
Ativa/Desativa
ph ativa
6) Modelo Entidade Relacionamento (MER) Dados descrevem coisas do mundo real. Itens de dados relacionados devem ser
agrupados Ex: nome, endereço, RG são informações
do sistema relacionados a uma entidade do mundo real que é o cliente.
Ainda podemos ter relacionamentos entre entidades
6) Modelo Entidade Relacionamento (MER)
DER – Diagrama Entidade Relacionamento
6) Modelo Entidade Relacionamento (MER)
DER – Diagrama Entidade Relacionamento
Exemplo
6) Modelo Entidade Relacionamento (MER) Existem muitas ferramentas Fácil de entender Não diz como se forma o atributo
CIC Não fica claro
7) Máquina de Estados Finitos (MEF) Os modelos de comportamento do
sistema devem mostrar estados eventos que alteram esses estados
Eventos são condições e ações para se mudar de estado.
7) Máquina de Estados Finitos (MEF)Uma MEF é dada por: (S, s0, I, ), S – conjunto finito e não vazio de
estados S0S – estado inicial I – conjunto finito de entradas (A
(ações) e C (condições)) que podem ser nulas
:SxI S - função de transição de estados
7) Máquina de Estados Finitos Diagrama de Estados (DTE)
7) Máquina de Estados Finitos Diagrama de Estados (DTE)
7) Máquina de Estados Finitos Diagrama de Estados (UML)
8) Dicionário de Dados (DD) Repositório de descrições de tudo
que é utilizado em um modelo Vantagens: organização, resolução
de ambigüidades e inconsistências, documentação, facilidade para relatórios, para alteração, etc
Integração com outros modelos – ferramenta automatizada
8) Dicionário de Dados (DD) Elemento Fluxo de Dados nome sinônimo origem: referência do processo destino: referência do processo descrição
informal formal
8) Dicionário de Dados (DD) Elemento Fluxo de DadosUma descrição mais formal representa
o fluxo com a seguinte notação: = é composto de + seqüência (e) ( ) opcional(pode ou não
estarpresente) { } iteração – { }n n repetições [ | ] ou exclusivo* comentários
8) Dicionário de Dados (DD) Elemento Fluxo de DadosEx1)nome = sobrenome + {int}n
0 + primeirosobrenome = string[30]int = string[60], primeiro = string[30]
Ex2)dados_pessoais = nome +endereço + estado civil +(dependentes)
8) Dicionário de Dados (DD) Elemento Fluxo de DadosEx3) exemplares = {exemplar} exemplar =
n_item+estado+nome_titulo n_item = cod_biblioteca+n_exemplar itens elementares de dados: cod_biblioteca = string[2] n_exemplar = inteiro nome_titulo = string[60]
8) Dicionário de Dados (DD) Elemento Depósito de Dados referência descrição fluxos de entrada e saída conteúdo
8) Dicionário de Dados (DD) Elemento Processo (Bolhas) referência descrição fluxos de entrada e saída resumo lógico
8) Dicionário de Dados (DD) Elemento Entidade Externa nome descrição outras informações importantes
9) O Modelo de Objetos – Principais Conceitos Objeto Abstração ou conceito do mundo real Encapsulamento de atributos e
serviços
Na análise – identificamos objetos no domínio do problema
No projeto – pensamos em objetos para a solução
9) O Modelo de Objetos – Principais Conceitos Classe Uma coleção ou agrupamento de um
ou mais objetos que podem ser descritos com os mesmos objetos e serviços.
Ex: os objetos mesa e cadeira, podem ser agrupados na classe mobília
9) O Modelo de Objetos – Principais Conceitos Atributo Característica, qualidade de um
objeto ou classe. Seus valores servem para
diferenciar objetos (Instâncias)
9) O Modelo de Objetos – Principais Conceitos
Ocultamento da Informação -Encapsulamento
Cada componente do programa deve conter uma única decisão de projeto.
A interface definida de forma a revelar o mínimo possível sobre o seu funcionamento interno.
9) O Modelo de Objetos – Principais Conceitos
Ocultamento da Informação -Encapsulamento
Reduz efeitos colaterais, facilita reuso, manutenção e testes, entendimento, etc.
Acessam-se dados de um objeto apenas com métodos do próprio objeto que funcionam como interface para outros objetos.
9) O Modelo de Objetos – Principais Conceitos Associações entre classes e objetos
relacionamentos entre as classes que em geral, representam a utilização de serviços e/ou a organização entre as mesmas.
devem refletir o domínio do problema
9) O Modelo de Objetos – Principais Conceitos
Hierarquia Generalização/Especialização
mostra generalizações de entidades do mundo real com características comuns e extensões destas características em casos especializados
super-classe – mais genérica sub-classe – mais específica
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Principais Conceitos Pode-se ter uma hierarquia ou um
entrelaçamento Pode-se herança múltipla Atributos e serviços comuns
devem ser colocados no nível superior
Deve satisfazer 100% a regra is-a
9) O Modelo de Objetos – Principais Conceitos
_________
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Principais ConceitosAgregação/Decomposição representa um composto e suas
partes um inteiro pode ser decomposto
em diferente partes, ou várias partes podem ser agregadas em um composto
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Principais ConceitosAgregação pode ser:
Composição: a parte pertence apenas a um único composto
Compartilhamento: a parte pode pertencer a mais de um composto
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Principais ConceitosMétodos ou Serviços Processamento realizado por um objeto
que indica o seu comportamento, em função do recebimento de uma mensagem
Mensagens Ativação de um método. Um objeto se
utiliza de um serviço ou se comunica com outro objeto enviando uma mensagem
9) O Modelo de Objetos – Principais ConceitosLigação Dinâmica (late binding) Mecanismo pelo qual se decide o
destino de uma mensagem em tempo de execução
Ex: int (*f)(); a função só definida i =f(); durante a execução
9) O Modelo de Objetos – Principais Conceitos
Sobrecarga de operadores (Overloading)
Operações de mesmo nome, mas implementadas de maneira diferente
Ex: operações de adição, subtração
implementadas diferentemente para real e inteiro
9) O Modelo de Objetos – Principais Conceitos
Polimorfismo Possibilidade de uma função poder
manipular valores com tipos (formas) diversas
Ex: function comp(L:lista):integer qualquer tipo de lista (genérico) mesma implementação
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Principais ConceitosConstrutor/Destrutor Função para criação/remoção de
instâncias de objetos/classes
Overriding (ou Sobreposição) Mecanismo para redefinir ou
tornar um atributo não aplicável
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Principais Conceitos
9) O Modelo de Objetos – Diagrama de Classes
9) O Modelo de Objetos – Diagrama de Classes Como Construir
Na fase de análise constrói-se primeiramente um diagrama de classes sem se preocupar em definir os métodos, ao qual chamaremos de Modelo Conceitual
Na fase de projeto os métodos são adicionados e o Modelo Conceitual refinado gerando o Diagrama de Classes
10) O Modelo Formal Utilizam notações matemáticas e
podem ser empregados em qualquer estágio da especificação de um sistema
Utilizam operadores relacionais: >, <,= ... operadores lógicos: ^, ~ ... quantificadores: , (para todo, existe) teoria dos conjuntos: ,,,, ...
10) O Modelo FormalEspecifica-se uma função em termos de: Pré-condições: para a função ser
executada Pós-condições: para a função terminar
Predicados sobre entradas e saídas das funções, geralmente parâmetros, dados
10) O Modelo FormalPassos Estabelecer restrições para os
valores de entrada Estabelecer restrições para os
valores de saída Combinar esses predicados em
pré e pós-condições
10) O Modelo FormalEx1) especificar que o código digitado é um
código cadastrado na base da biblioteca b biblioteca/ (b.código=código_biblioteca)
Ex2) especificar que todo exemplar identificado por n_item (número do item) pertence a alguma biblioteca
e exemplar/ pertence(b.código, e.n_item)
10) O Modelo FormalEx3) especificar função localiza_exemplar(exemplar_disponível:string):strin
gPré-condição b biblioteca/ pertence(b.código, exemplar_disponível)
Pós-condição b biblioteca/
(b.nome=localiza_exemplar(exemplar_diponível) ^ pertence(b.código, exemplar_disponível)
10) O Modelo FormalEx4) especificar que um exemplar está
disponível em apenas uma biblioteca e reservado apenas para disciplinas de sua área
e exemplar( b1,b2 biblioteca (disponível (b1,e) ^
disponível (b2,e)) b1=b2))^( d disciplina (reservado(d,e)) area
(d,e))
10) O Modelo Formal – Linguagem Z
Baseada em teoria dos conjuntos e lógica de primeira ordem
Constrói-se um esquema que agrupa declarações de variáveis e predicados que restrigem os valores dessas variáveis.
Ex: ______ x ________ Inível: F N decl. var. declarações ______________ ________________ Inível predicado predicados