professor mário dantas set/2010 e ngenharia de s oftware
TRANSCRIPT
![Page 1: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/1.jpg)
Professor Mário DantasSet/2010
ENGENHARIA DE SOFTWAREENGENHARIA DE SOFTWARE
![Page 2: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/2.jpg)
Aula 03 - Agenda
Engenharia de Requisitos
![Page 3: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/3.jpg)
Objetivos
Conhecer os conceitos e técnicas relacionadas a engenharia de requisitos, bem como sua aplicação;
Saber as diferenças entre os requisitos de software funcionais e não funcionais;
Entender como os requisitos podem ser organizados em um documento de requisitos.
![Page 4: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/4.jpg)
Seu pior pesadelo
Um cliente entra no seu escritório, senta-se, olha você direto nos olhos e diz:
“Eu sei que você pensa que entende o que eu disse, mas o que você não entende é que, o que eu disse, não é o que eu queria dizer.”
![Page 5: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/5.jpg)
Requisitos
![Page 6: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/6.jpg)
Definições
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.
Sommerville (2007), as descrições das funções e restrições são os requisitos do sistema.
SWEBOK (2004), um requisito é descrito como uma propriedade que o software deve exibir para resolver algum problema no mundo real.
![Page 7: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/7.jpg)
Definições
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.
![Page 8: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/8.jpg)
Importância dos Requisitos
Resultados de um estudo feito pelo Standish Group em 350 companhias e 8000 projetos de software (Pfleeger, 2004): 31% dos projetos cancelados antes de
estarem completos Em pequenas companhias, somente 16% dos
projetos foram entregues no prazo e no orçamento inicialmente estabelecido
Em grandes companhias, apenas 9% estão de acordo com esses critérios
![Page 9: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/9.jpg)
Importância dos Requisitos
O Standish Group classificou os projetos em 3 categorias:
Sucesso (16,2%) : Cobre todas as funcionalidades, em tempo e dentro do custo previsto (cronograma e orçamento)
Problemático (52,7%) : Não cobre todas as funcionalidades exigidas, custo aumentado e/ou com entregas em atraso.
Fracasso (31,1%): Cancelado durante o desenvolvimento
![Page 10: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/10.jpg)
Desafios
Compreensão do domínio do problema. Comunicação efetiva com reais usuários
e clientes do sistema. Evolução contínua dos requisitos do
sistema.
![Page 11: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/11.jpg)
Domínio
O termo, no contexto da engenharia de software, é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais, que exibem características similares.
É definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.
![Page 12: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/12.jpg)
Especificação de Requisitos
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 do software.
![Page 13: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/13.jpg)
Por que precisamos de requisitos?
Para entender o que o cliente quer
Para documentar o que o cliente quer
Para assegurar a qualidade e a satisfação do cliente
Para entender o problema do negócio
Para documentar o escopo do projeto e definir suas restriçõesPara definir critérios de aceitação e gerenciar as expectativas do cliente
![Page 14: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/14.jpg)
Engenharia de Requisitos
![Page 15: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/15.jpg)
Definição
Sommerville (2003), Engenharia de Requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema.
![Page 16: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/16.jpg)
Engenharia de Requisitos
O processo de descobrir, analisar, documentar e verificar as descrições dos serviços
fornecidos pelo sistema e as suas restrições operacionais.
![Page 17: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/17.jpg)
Engenharia de Requisitos
“Entender os requisitos de um problema está entre as tarefas mais
difíceis enfrentadas por um engenheiro de software.” (Pressman, R.)
![Page 18: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/18.jpg)
Engenharia de Requisitos
Descreve as atividades relacionadas à investigação e definição de escopo de um sistema de software.
Processo sistemático de produção de requisitos por meio de atividades cooperativas de análise em que os resultados são documentados em uma variedade de formatos e a precisão das observações é constantemente verificada.
![Page 19: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/19.jpg)
Questionamentos Típicos
Como seguir um processo pré-estabelecido se tantos fatores são desconhecidos no início do desenvolvimento do software?
Os fatores desconhecidos serão melhor elucidados e os riscos serão minimizados com um processo sistemático, iterativo e incremental.
![Page 20: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/20.jpg)
Questionamentos Típicos
Quantas iterações são necessárias para verificar a correção e a precisão das observações?
A quantidade de iterações ideal será aquela suficiente para que cliente e fornecedor sintam-se seguros e concordem com o que está definido, mesmo com o que surgir de novo e for aceito para o escopo do projeto.
![Page 21: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/21.jpg)
Questionamentos Típicos
Quais representações e notações devem ser usadas na captura e documentação dos requisitos?
As representações e notações devem estar previstas no processo de software e no método adotado por esse processo. Tipicamente, são usados casos de uso e suas especificações .
![Page 22: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/22.jpg)
Questionamentos Típicos
Qual o nível de precisão e formalidade dos requisitos?
Dependerá de quão crítico é o sistema e das características do cliente.
![Page 23: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/23.jpg)
Questionamentos Típicos
Como sabemos que chegamos ao final do processo?
Similarmente à quantidade de iterações, até que haja uma base sólida de concordância entre o desenvolvedor e o cliente
![Page 24: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/24.jpg)
Visão Geral
Produção de Requisitos
Levantamento
Registro
Obtenção de Comprometimento
Verificação
Gerência de Requisitos
Controle de Mudança
Gerência de Configuração
Rastreabilidade
Gerência de Qualidade de
Requisitos
Engenharia de Requisitos
![Page 25: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/25.jpg)
Síntese dos Objetivos
Estabelecer uma visão comum entre o cliente e a equipe de projeto sobre os requisitos que serão atendidos;
Registrar e acompanhar requisitos ao longo de todo o desenvolvimento;
Documentar e controlar os requisitos para estabelecer uma base para uso gerencial e da equipe de desenvolvimento;
Manter planos, artefatos e atividades de software coerentes com os requisitos alocados.
![Page 26: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/26.jpg)
Uma Última Questão
O que acontece se: O usuário mudar de idéia 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 ter entendido corretamente a necessidade do usuário?
![Page 27: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/27.jpg)
Gerência de Mudança
É preciso gerenciar as mudanças! Mudanças em requisitos ao longo do
processo fazem parte do desenvolvimento de software.
Alterações em requisitos podem implicar mudanças em artefatos de projeto, de código, casos de testes, etc.
![Page 28: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/28.jpg)
Identificação dos Requisitos
Trata-se da identificação dos requisitos em si para formação da idéia inicial do sistema e compreensão do domínio do problema.
“Trabalhe com os usuários e não contra eles” (AMBLER).
“Temos que aceitar a instabilidade dos requisitos como um fato da vida, e não condená-la como o resultado de um raciocínio mal conduzido” (COAD).
![Page 29: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/29.jpg)
Ações com Foco no Usuário
Identificar Objetivos de Negócio (Por que desenvolver algo?)
Identificar Stakeholders (Quem está envolvido?)
Obter diferentes Pontos de Vista (Com que os stakeholders estão preocupados? Existem conflitos?)
Resolver Conflitos Identificar Cenários (Quais resultados as
pessoas desejam? Sob que circunstâncias?)
![Page 30: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/30.jpg)
Problemas Comuns
Escopo: O limite do sistema é mal definido, ou detalhes técnicos desnecessários confundem os objetivos globais
Entendimento: Os clientes e 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
Volatilidade: Os requisitos mudam com o tempo
![Page 31: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/31.jpg)
Desafios a Suplantar
Falta de conhecimento do usuário das suas reais necessidades e do que um produto de software pode oferecer
Falta de conhecimento do desenvolvedor sobre o domínio do problema
![Page 32: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/32.jpg)
Habilidades do Desenvolvedor Dominar o processo de produção de
requisitos e suas técnicas Ouvir o que os usuários têm a dizer sem
induzi-los a aceitar visões e interpretações já vivenciadas pela equipe
Comunicar adequadamente aos usuários e clientes a evolução do trabalho e suas limitações
A produção de requisitos é um processo social
![Page 33: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/33.jpg)
Classificação de Requisitos
Classificação Comum: Requisitos Funcionais Requisitos Não Funcionais Requisitos do Domínio
![Page 34: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/34.jpg)
Outras Classificações para Requisitos
Requisito do usuário: declarações sobre as funções que o sistema deve oferecer
Requisito do sistema: detalhamento das funções e das restrições (contrato entre cliente e desenvolvedor)
Requisito do projeto: define como o projeto deve ser conduzido e que artefatos devem ser produzidos (escopo do projeto).
![Page 35: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/35.jpg)
Requisitos Funcionais
Requisitos diretamente ligados ao comportamento do software
Descrevem as funções que o software deve executar
Descrevem as interações entre o sistema e seu ambiente
“O software deve permitir que o atendente consulte o relatório com os resultados dos testes clínicos de um paciente”.
![Page 36: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/36.jpg)
Exemplos
[RFO1] O software deve permitir que o atendente efetue cadastro de clientes.
[RFO2] O software deve permitir que o caixa efetue o registro de itens vendidos.
[RFO3] O software deve permitir que o administrador gere o um relatório de vendas por mês.
![Page 37: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/37.jpg)
Exercícios
Escreva três requisitos funcionais para sistemas a serem desenvolvidos para os seguintes domínios:
Vídeo Locadora Apoio Inteligente à Análise de Risco para
Bolsa de Valores Sistema de Caixa de Auto-atendimento
de um Sistema Bancário.
![Page 38: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/38.jpg)
Uma Solução Possível
Vídeo Locadora: O software deve permitir que o administrador efetue o
cadastro de clientes O software deve permitir que o administrador efetue o
cadastro de DVDs O software deve permitir que o atendente efetue o
registro de DVDs alocados Auto-atendimento Bancário:
O software deve permitir que o cliente consulte seu extrato
O software deve permitir que o cliente efetue saque; O software deve permitir que o cliente efetue o
pagamento da fatura do cartão de crédito.
![Page 39: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/39.jpg)
Soluções Possíveis
Apoio Inteligente à Análise de Risco para Bolsa de Valores
O domínio da aplicação pode dificultar – e muito – o trabalho de produção dos requisitos!
![Page 40: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/40.jpg)
Requisitos Não Funcionais
São requisitos que expressam condiçõ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 impõem restrições ao sistema.
Podem ser mais críticos que requisitos funcionais, chegando a tornar um sistema impossível ou inútil.
![Page 41: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/41.jpg)
Exemplos
“As consultas ao sistema devem ser respondidas rapidamente”
“As consultas ao sistema devem ser respondidas em menos de três segundos”
Requisitos Não Funcionais devem ser mensuráveis e estar associados a uma
forma de medida ou referência
![Page 42: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/42.jpg)
Medidas para Requisitos Não Funcionais
Propriedade Medida
Velocidade Transações processadas por segundoTempo de resposta do usuário/evento
Tamanho KbytesNum. De chips de RAM
Facilidade Tempo de treinamentoNum. Quadros de ajuda
Confiabilidade Tempo médio de falhasProbabilidade de indisponibilidadeTaxa de ocorrência de falhas
Robustez Tempo de reinício após a falhaPercentual de eventos causando falha
Portabilidade Num. de sistemas destino
![Page 43: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/43.jpg)
Classificação dos RNF
![Page 44: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/44.jpg)
Classificação dos RNF
RNF do Produto: Produto deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc.)
RNF Organizacionais: Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc.)
RNF Externos: Conseqüência de fatores externos ao sistema e ao processo de desenvolvimento (legislação, etc.)
![Page 45: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/45.jpg)
RNF do Produto
RNF de usabilidade: usuários devem ser capazes de usar as funções do sistema após duas horas de treinamento
RNF de confiabilidade: o sistema deve estar disponível 99% das vezes
RNF de segurança: o acesso aos dados deve ser protegido, conforme RN
RNF de desempenho: o sistema deve processar n requisições por segundo
RNF de capacidade: o sistema deve suportar n usuários concorrentemente
RNF de portabilidade: o sistema deve rodar nas plataformas X e Y
![Page 46: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/46.jpg)
RNF Organizacionais
São procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor:
RNF de entrega: um relatório de progresso deve ser entregue a cada duas semanas
RNF de implementação: o sistema deve ser implementado na linguagem Java
RNF de padrões e métodos de desenvolvimento: uso de métodos orientados a objetos; desenvolvimento utilizando a ferramenta X
![Page 47: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/47.jpg)
RNF Externos
Impostos tanto ao produto quanto ao processo de desenvolvimento em função do ambiente no qual o sistema é desenvolvido:
RNF de interoperabilidade: o sistema deve interagir com os sistemas X e Y
RNF de restrições éticas: o sistema não deverá revelar aos operadores nenhuma informação pessoal dos clientes
RNF de restrições legais: o sistema deverá armazenar as informações de acordo com a Lei número XXYY de ZZ
![Page 48: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/48.jpg)
Exercício
Forneça alguns exemplos de requisitos não funcionais (RNF) para, classifique-os:
1. Vídeo Locadora2. Sistema de Auto-atendimento Bancário
![Page 49: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/49.jpg)
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 gerar requisitos funcionais novos ou restrições sobre os existentes
São regras de negócio (RN)
![Page 50: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/50.jpg)
Problemas
Entendimento 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 Aspectos Implícitos
Especialistas no domínio entendem a área tão bem que assumem que os requisitos estão claros para os desenvolvedores
![Page 51: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/51.jpg)
Exemplos
[RN1] Os campos referentes a “Orçamento Projeto Vinculado” só estarão ativos se o tipo de projeto for Vinculado.
[RN2] O campo Valor Total Orçado para o Projeto é calculado somando-se os valores definidos para todas as rubricas incluídas no orçamento do projeto, seja ele vinculado ou não-vinculado.
[RN3] A soma dos percentuais a ser distribuído entre os fundos incluídos no plano de aplicação deve ser entre 0 e 100%
![Page 52: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/52.jpg)
Exercício
Forneça alguns exemplos de requisitos de domínio (RN) para:
1. Vídeo Locadora2. Sistema de Auto-atendimento Bancário
![Page 53: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/53.jpg)
Respostas
Vídeo locadora: [RN1] O software deve permitir que o
cliente alugue no máximo 2 filmes na primeira locação.
Sistema de Auto-atendimento Bancário: [RN1] O cliente pode sacar o valor máximo
de R$ 100,00 por dia.
![Page 54: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/54.jpg)
Processo de Engenharia de Requisitos
![Page 55: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/55.jpg)
Processo de ER
Ambiente ideal: clientes e engenheiros de software trabalhando juntos na mesma equipe.
Neste caso, a ER é simplesmente uma questão de conduzir conversas entre colegas que são membros bem conhecidos da equipe.
Exemplo: Desenvolvimento ágil de software.
![Page 56: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/56.jpg)
Processo de ER
Ambiente real: clientes em cidade ou país diferente, com uma vaga idéia do que é necessário, opiniões conflitantes sobre o sistema a ser construído, conhecimento técnico limitado, tempo limitado para interagir com o engenheiro de requisitos, etc.
Nada disso é desejável, mas são situações comuns em que a equipe de software é forçada a trabalhar.
![Page 57: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/57.jpg)
Processo de ER
Trata dos passos necessários para conduzir a Engenharia de Requisitos.
Busca colocar o projeto em andamento e mantê-lo em movimento até se alcançar uma solução bem-sucedida.
![Page 58: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/58.jpg)
Identificação dos interessados
Interessado: qualquer um que se beneficie de modo direto ou indireto do sistema que está sendo desenvolvido.
O engenheiro de requisitos deve criar uma lista de pessoas que fornecerão entradas à medida que os
requisitos forem levantados.
Com quem mais vocês acham que eu deveria falar?
Início do Processo
![Page 59: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/59.jpg)
Diferentes pontos de vista
Requisitos inconsistentes e conflitantes
O engenheiro de requisitos deve categorizar todas as informações dos interessados a fim de que os tomadores de decisão escolham um conjunto de requisitos consistente.
Busque a colaboração entre os interessados.
Início do Processo
![Page 60: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/60.jpg)
Primeiras questões
Engenheiro de Requisitos: Quem solicitou? Quais são os usuários? Qual o benefício econômico? Há outra fonte para a solução?
Equipe de Software: Quais são as saídas geradas? Qual o ambiente de negócios da solução? Restrições de desempenho afetarão a solução?
Início do Processo
![Page 61: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/61.jpg)
Primeiras questões
Você é a pessoa certa para responder a essa questões? Suas respostas são “oficiais”?
Alguém mais pode fornecer informações adicionais?
ATENÇÃO: Essas e outras questões ajudam no início da comunicação, entretanto, não abuse delas durante as reuniões.
Início do Processo
![Page 62: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/62.jpg)
Coleta colaborativa de requisitos
Especificar o problema Propor elementos da solução Negociar abordagens Especificar um conjunto inicial de
requisitos
Reuniões
Levantamento de Requisitos
![Page 63: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/63.jpg)
As reuniões são conduzidas e assistidas por engenheiros de software, clientes e outros interessados.
São definidas regras para a preparação e a participação. É sugerida uma agenda suficientemente formal para cobrir todos os pontos importantes, porém suficientemente informal para encorajar o livre fluxo de idéias.
Um “facilitador” (cliente, desenvolvedor ou outra pessoa) controla a reunião.
Levantamento de Requisitos
![Page 64: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/64.jpg)
Um “mecanismo de definição” é usado (folhas de rascunho, flip charts, quadro de avisos eletrônico, fórum virtual, etc).
A meta é identificar o problema, propor elementos da solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da solução.
Levantamento de Requisitos
![Page 65: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/65.jpg)
Quais são os produtos finais desta etapa?
Declaração da necessidade e viabilidade Escopo do problema Clientes, usuários que participaram Lista de requisitos Conjunto de cenários de uso (descrição
de como o sistema será usado) Protótipos
Levantamento de Requisitos
![Page 66: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/66.jpg)
Análise de Requisitos
Objetivo
Estabilidade do modelo à medida que ele evolui
Elementos do Modelo de AnáliseElementos baseados em cenários.
Exemplo: casos de usoElementos baseados em classes.
Exemplo: diagramas de classesElementos comportamentais. Exemplo:
diagramas de seqüênciaElementos orientados a fluxo
![Page 67: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/67.jpg)
Negociação
Funcionalidades e desempenho podem ser questionados em função do custo e do prazo
Clientes (necessidades satisfeitas) e desenvolvedores (orçamentos e prazos realistas) ganham.
“Conciliação é a arte de dividir um bolo de tal modo que todos acreditam ter o maior pedaço.”
(Ludwing Erhard)
![Page 68: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/68.jpg)
A arte da negociação
Reconheça que não é uma competição Trace uma estratégia Ouça atentamente Focalize os interesses das outras partes Não deixe a coisa ficar pessoal Seja criativo Esteja pronto a se comprometer
Negociação
![Page 69: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/69.jpg)
Validação
Requisito consistente com o objetivo, sem restrições contraditórias?
Requisitos estão especificados em um nível de detalhes suficiente?
Todas as funções foram incluídas? Há necessidade do requisito? Ambigüidade? Requisitos conflitantes? Requisitos podem ser testados?
![Page 70: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/70.jpg)
Técnicas de Validação
Revisões de requisitos: podem ser formais ou informais. As revisões formais devem ser conduzidas através da verificação da consistência, erros e completeza do requisito.
São verificadas também: facilidade de verificação; facilidade de compreensão; adaptabilidade: alterações no requisito podem
provocar efeitos significativos?
Levantamento de Requisitos
![Page 71: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/71.jpg)
Gerenciamento de Requisitos
Requisitos para grandes produtos são modificados freqüentemente
Diversidade de usuários (diferentes requisitos e prioridades)
Restrições orçamentárias e organizacionais X requisitos dos usuários finais
Modificações na empresa e no ambiente técnico
Impacto das mudanças do requisito (facilidade de rastreamento)
![Page 72: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/72.jpg)
O Processo de Engenharia de Requisitos
![Page 73: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/73.jpg)
Estrutura de um Documento de Requisitos
Prefácio Introdução Glossário Definição dos Requisitos do Usuário Arquitetura de Sistemas Especificação de Requisitos do Sistema Modelos de Sistema Evolução de Sistema Apêndices Índice
![Page 74: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/74.jpg)
Atividade
Praticando o Processo de Engenharia de Requisitos.
Cada grupo será responsável por elaborar um documento de requisitos para um dos domínios abaixo: Locadora de Vídeo Universidade Atendimento ao cliente
Algum outro domínio escolhido pelo grupo deve ser apresentado previamente ao professor.
![Page 75: Professor Mário Dantas Set/2010 E NGENHARIA DE S OFTWARE](https://reader036.vdocuments.net/reader036/viewer/2022062700/552fc12b497959413d8d0b59/html5/thumbnails/75.jpg)
Orientações Gerais
Elaborar um documento de requisitos com base nas tarefas de concepção, levantamento, elaboração, negociação, especificação, validação e gestão de requisitos.
Grupos de até 5 alunos Apresentação na próxima aula Duração: 5 minutos Entregar documento de requisitos (até 4
páginas), conforme o modelo entregue ao Aluno.
Dica: definir um papel para cada integrante do grupo. Exemplo: gerente da empresa, usuário final, engenheiro de software, desenvolvedor, etc.