Escolar Documentos
Profissional Documentos
Cultura Documentos
Custo de correo
Custo de correo
O custo de 1 problema 200 vezes maior se reparado aps a implantao. Os erros mais caros so aqueles cometidos na Anlise de requisitos e descobertos pelo usurio!
3
Definies
Requisitos de Software
Sentenas que expressam as necessidades dos clientes e que condicionam a qualidade do software.
Tipos de Requisitos
Requisitos Funcionais
RF so requisitos diretamente ligados a funcionalidade do software.
Requisitos No Funcionais
RNF so requisitos que expressam restries que o software deve atender ou qualidades especficas que o software deve ter.
Exemplos
O sistema deve prover um formulrio de entrada para a entrada dos resultados dos testes clnicos de um paciente. (RF) O sistema deve emitir um recibo para o cliente, com o tempo mximo de 8 segundos aps a transao. (RF, RNF de performance). O sistema no pode apagar informao de um cliente (RIN).
6
Definies
A engenharia de requisitos estabelece o processo de definio de requisitos como um processo no qual o que deve ser feito deve ser elicitado, modelado e analisado. Este processo deve lidar com diferentes pontos de vista, e usar uma combinao de mtodos, ferramentas e pessoal. O produto desse processo um modelo, do qual um documento chamado requisitos produzido. Este processo perene e acontece num contexto previamente definido a que chamamos de Universo de Informaes.
Quanto mais tarde um erro detectado, maior o custo de corrigi-lo. Muitos erros nos requisitos podem ser detectados cedo no ciclo de desenvolvimento. Erros tpicos incluem fatos incorretos, omisses, inconsistncias e ambiguidade.
Porqu difcil?
Fonte Steve Easterbrook
Problemas tem fronteiras mal definidas (abertos) Requisitos esto no contexto organizacional (inclinados a conflitos) Solues para os problemas da anlise so artificiais Problemas so dinmicos Requer conhecimento interdisciplinar e habilidades especficas
9
Engenharia de Requisitos
10
Processo essencial
Entender o problema
ELICITAO
Modelar o problema
MODELAGEM
Representar nosso entendimento do problemas utilizando tcnicas para modelagem: DFD, MER, casos de uso...
Analisar o problema
ANLISE
Processo
Anlise Elicitao Modelagem V&V
12
Elicitao
Mundo Real
Inspirao: Guilherme Nicodemos -UCP
Problemas
Solues
Gap Semntico
Mundo Computacional
Elicitao de Requisitos
13
Elicitao
Fonte Julio Cesar Leite
14
Quem o cliente? Quem o dono do sistema? Existe alguma soluo (pacote) disponvel? Quais so os livros relacionados aplicao em discusso? Existe a possibilidade de reutilizar os artefatos (software)?
16
Coleta de Fatos
Leitura de documentos Observao Entrevistas Reunies Questionrios Antropologia Participao ativa dos atores Bases de Requisitos no funcionais Engenharia Reversa Reutilizao
17
Conhecimento Tcito
18
Elicitao
Perguntar porqu?
A cafeteira deve ser feita de ao qual a razo disto? pode me explicar porqu? qual o pensamento atrs disto?
19 Ian Alexander, Writing better requirements
Elicitao
Porque se for de vidro pode quebrar
Requisito real A cafeteira deve ser feita de material inquebrvel
Plstico Poliuretano At mesmo ao
Exerccio
a cafeteira tem uma luz vermelha que pisca quando est ligada, quando a gua chega na temperatura certa ela fica ligada (sem piscar)
Quais seriam as perguntas do tipo porque que poderiam ser utilizadas nesta situao? Quais seriam os reais requisitos?
Dica: Separar requisito de soluo/implementao
21
Observao
22
Entrevistas
Fonte Julio Cesar Leite
+
contato direto com atores possibilidade de validao imediata
23
Reunies
Fonte Julio Cesar Leite
24
Reunies
Fonte Julio Cesar Leite
+
dispor de mltiplas opinies criao coletiva
disperso custo
25
Observao
Fonte Julio Cesar Leite
26
Enfoque antropolgico
Fonte Julio Cesar Leite
+
viso de dentro para fora contextualizada
27
Leitura de Documentos
Fonte Julio Cesar Leite
+
facilidade de acesso s fontes de informao volume de informao
disperso das informaes volume de trabalho requerido para identificao dos fatos
28
Questionrios
Fonte Julio Cesar Leite
29
Exemplos
Fonte Julio Cesar Leite
Quantitativo
5. A XXX mantm dados estatsticos sobre o processo de desenvolvimento de software?
60 55 50 45 40 35 30 25 20 15 10 5 0 NO SIM
Num. de Respostas
30
Exemplos
Fonte Julio Cesar Leite
8. Durante o processo de produo verificada uma alterao nos requisitos. Esta alterao:
60 55 50 45 40 35 30 25 20 15 10 5 0 1 (No registrada) 2 3 4 5 ( registrada, mas no ( registrada formalmente no documento de requisitos) no documento de requisitos)
Num. de Respostas
31
Exemplos
Fonte Julio Cesar Leite
Qualitativo
O qu voc acha da sua formao no que se refere a produo de software de qualidade? O que voc acredita ser necessrio para aprimorar seu desempenho? Que conhecimentos voc desejaria adquirir? Por qu? Objetivo: verificar a opinio em relao a poltica de trainamento Justificativa: uma organizao madura tem polticas bem definidas de treinamento. Pergunta de controle
32
Controle
Fonte Julio Cesar Leite
1. Como voc classifica o treinamento existente em gerncia de qualidade na XXX?
2. Como voc classifica o treinamento existente em gerncia de requisitos na XXX?
60 55 50 45 40 35 30 25 20 15 10 5 0 1 (Inexistente) 2 3 (Espordico) 4 5 (Muito bom)
Num. de Respostas
Num. de Respostas
Num. de Respostas
33
Questionrios
Fonte Julio Cesar Leite
+
padronizao de perguntas tratamento estatstico
34
35
Taxonomia
Portabilidade Independncia Auto conteno Confiabilidade utilidade como- Eficincia Engenharia Humana Preciso Completeza Integridade/Robustez Consistncia Responsabilidade Testabilidade Eficincia de dispositivo Acessabilidade Compreensiblidade Comunicao Modifiabilidade Auto descrio Estrutura Conciso Legibilidade
Utilidade geral
manutenibilidade
Boehm 76
Aumentabilidade
36
Taxonomia
Requisitos no funcionais
Requisitos de Processo
Requisitos de Produto
Requisitos Externos
requisitos de usabilidade
requisitos de eficincia
requisitos de confiabilidade
requisitos de portabilidade
requisitos de entrega
requisitos de implementao
requisitos legais
requisitos de custo
requisitos de interoperabilidade
Sommerville 92
requisitos de performance
requisitos de espao
37
Requisitos No Funcionais
Requisitos no funcionais devem ser elaborados at que se tornem verificveis
Requisito Inverificvel
O banco de dados ZZ deve ser flexvel MNOP deve ser seguro
Requisito Verificvel
O banco de dados ZZ deve possuir oito campos por registro.
MNOP deve parar sua operao se uma pessoa se aproximar a mais de 2 metros de uma de suas partes mveis MNOP deve desligar os aquecedores se a temperatura da gua exceder 37C MNOP deve estar dentro dos padres estabelecidos pela norma N567 seo 3.6 para temperaturas de superfcies externas.
O sistema CE deve escanear os dados do usurio e conta de cada folheto de depsito em 2 segundos ou menos
38
Requisitos inverificveis
Algumas
palavras levam a requisitos impossveis de serem verficados Palavras no Verificveis Possveis substitutos
Nmero mximo de passos Lista de funcionalidades presentes em outras aplicaes Menus ou prompts para auxiliar usurios Dimenses Requisitos mnimos de hardware Sistemas operacionais em que deve funcionar Dimenses aceitveis (em nmero de Bytes)
Variveis que podem acomodar uma gama de mudanas de valores Funes que implementam uma de vrias possibilidades 39
Base de RNFs
Fonte Julio Cesar Leite
+
reutilizao de conhecimento antecipao de aspectos implementacionais identificao de conflitos
Engenharia Reversa
Fonte Julio Cesar Leite
41
Reutilizao
Fonte Julio Cesar Leite
+
produtividade qualidade
42
Modelagem
Mundo Computacional
Modelagem
Mundo Real
Inspirao: Guilherme Nicodemos -UCP
Solues
Problemas Gap Semntico
Modelar
45
Abstrao
Fonte: S. Easterbrook - UofT
Em programao
Abstrao o processo de nomear objetos compostos e lidar com eles como se fossem entidades nicas
No resolve problemas
Mas simplifica!!!
46
Decomposio
Decompor o problema at:
Cada subproblema esteja no mesmo nvel de detalhe Cada subproblema possa ser resolvido de modo independente As solues de cada subproblema possam ser combinadas de modo a resolver o problema original
Vantagens:
Pessoas diferentes podem trabalhar nos subproblemas Paralelizao pode ser possvel Manuteno mais fcil
Desvantagens
As solues dos subproblemas podem no combinar de modo a resolver o problema original Problemas de difcil compreenso so difceis de decompor A estrutura do mundo real NO hierrquica [Jackson]
47
Durante algum tempo vistas como tcnicas de requisitos (anlise) Mais utilizadas:
DFD, JSD, Tabelas de Deciso, Mquinas de Estado (StateChart), SADT, Eventos Externos, MER, Dicionrio de Dados.
48
Casos de Uso
Fceis de entender (escritos na linguagem do problema) Ajudam a unificar critrios Estimulam o pensamento Ajudam no treinamento Ajudam no rastreamento Ajudam na identificao de requisitos no-funcionais
situaes
49
2. 3. 4. 5. 6.
Fluxo bsico: O caso de uso inicia quando chega a vez do cliente na fila do caixa. (seleciona promoo). (bebida). Funcionrio oferece a opo de aumento de B&B. (sobremesa). Cliente decide se o pedido para viagem ou para agora.
50
Casos de Uso
51
Ator (Actor)
Abertura do Caixa
53
Casos de Uso
Oferecem uma maneira intuitiva e sistemtica para capturar os requisitos FUNCIONAIS Foco no conceito de valor adicionado (added value) ao cliente Podem ser utilizados para guiar o processo de desenvolvimento
54
Valor adicionado
Perguntar aos clientes/usurios o que eles gostariam que o sistema fizesse no funciona:
Lista de funcionalidades que pode parecer til a princpio, mas na verdade...
Representao
Casos de Uso so fundamentalmente textuais (tambm podem ser representados atravs de flow charts, diagramas de sequncia, redes de Petri e diagramas de estado) Diagramas de Caso de uso representao grfica (mostra os atores e os casos de uso em que esto envolvidos)
56
Escopo: conselheiro/pacote financeiro(PAF) Nvel: objetivo do usurio Interessados e interesses: comprador- quer comprar aes e t-las adicionadas ao portflio PAF automaticamente Financeira quer informao de compra Pr condio: usurio tem o PAF aberto Garantia mnima: informao de log suficiente de modo que o PAF possa detectar erros e solicitar mais detalhes Garantia de sucesso: Site remoto tem conhecimento da compra, dos logs e o portfolio do usurio atualizado Cenrio de Sucesso Principal: 1. Comprador seleciona aes na internet 2. PAF pega nome do web site a ser utilizado (Schwab, E trade) 3. PAF abre conexo para o site, retendo o controle 4. Comprador navega e compra ao do site 5. PAF intercepta respostas do site da web e atualiza portfolio 6. PAF mostra o novo portfolio Extenses: 2a. Comprador seleciona um site que o PAF no trabalha 2a1. Sistema recebe novas sugestes do comprador, com opo de cancelar o caso de uso
57
Sistema
fluxo principal
O Caixeiro faz a abertura da venda.
O Merci notifica o Sistema Financeiro informando: Data, Nmero da Operao de Venda, Receita, Valor Total, Nome do Cliente (caso tenha sido emitida a nota fiscal).
59
Nome
Descrio Atores Disparadores
2.
Fluxo de eventos
Fluxo bsico Fluxo alternativo
Condio 1 Condio 2
3.
Requisitos Especiais
Plataforma
4. 5. 6.
Sentenas de Requisitos
O sistema deve + [verbo + objeto | frase verbal ] + [complemento de agente | nulo] + [condies | nulo] Trs classes de sentenas: {Entrada, Sada, Mudana de Estado} Verbo um verbo simples que expresse a funcionalidade daquele requisito Frase verbal uma frase que expressa a funcionalidade do requisito Complemento de agente a identificao de um agente relacionado com o requisito; esse complemento pode ser descrito pelo objeto indireto. Agente pode ser uma pessoa, uma instituio, um grupo ou um dispositivo fsico externo ao software As sentenas podem ser de trs tipos: funcionais, nofuncionais e inversas.
61
Sentenas de Requisitos
O sistema deve emitir um recibo para o cliente. O sistema deve emitir o recibo para o cliente em no mximo 2 segundos. O sistema deve cadastrar o cliente, desde que o cliente possua identificao. O sistema deve transformar uma fita disponvel em fita emprestada, quando a fita for alugada pelo cliente. O sistema deve cadastrar bibliotecrios. O sistema deve verificar a identidade do bibliotecrio. O sistema no pode deixar que um livro fique na reserva mais de um ms. O sistema deve tornar um livro em livro emprestado, quando um usurio pegar este livro emprestado.
62
63
Clareza
Um requisito claro
Tipo de usurio Resultado desejado Objeto Condies O engenheiro de teste simula erros de componente . utilizando as funes de teste QQ e TT.
Um requisito vago
Em geral o sistema Precisa ou no? Quais? Como verificar isto? deve ser capaz de diagnosticar possveis erros em um prazo razovel.
64
Ambiguidade
O sistema deve enviar relatrios de produtividade dos programadores, analistas ou desenvolvedores do projeto mensalmente ou quando requisitado.
"Realizar rotina de importao de dados peridica de preo de fluido "Identificar e associar as intervenes que so complementares s outras" O sistema deve emitir uma mensagem de ateno visual ou auditiva no evento de falha do sistema de refrigerao.
65
Requisitos Incompletos
Curva S (Planejado X Realizado) de um projeto Cadastro de iniciativas estratgicas Cadastro de iniciativas de melhoria Acompanhamento das atividades Acompanhamento dos projetos (percentual de concluso)
66
Requisitos Mltiplos
No evento de falha da rede eltrica, o sistema deve enviar mensagem de erro ao usurio, salvar a configurao atual do sistema e os dados entrados, at ento. O sistema deve manter dados estatsticos sobre compra, venda e movimentao do estoque de materiais de limpeza. Informao relativa a comisso de vendedores tambm deve ser mantida. Cadastro das atividades de um projeto e produtos e funcionrio alocados na atividade
67
O sistema deve mostrar o total do pedido a medida em que os cdigos dos produtos vo sendo entrados no pedido, a no ser que se trate de um produto promocional.
68
(Projetos coordenados por um funcionrio) Atividades responsveis por um funcionrio O sistema poder ser acessado remotamente por qualquer unidade internacional da Petrobras, com isso, ele dever ter um desempenho compatvel ao acesso. Na improvvel eventualidade de falha no sistema de refrigerao, o sistema deve mandar mensagem para a chave admin
69
Anlise
Mundo Computacional
Anlise
Mundo Real
Inspirao: Guilherme Nicodemos -UCP
Problemas
Anlise de Requisitos
71
Verificao X Validao
Fonte Julio Cesar Leite
Verificao
estamos construindo o produto de maneira certa? (em relao a outros produtos)
Validao
estamos construindo o produto certo? (em relao a inteno dos fregueses)
entre modelos
Identificao de partes
Fonte Julio Cesar Leite
Depende da organizao e armazenamento museu britnico ???? ligada a identificao das fontes de informao 90% dos problemas em 10% do sistema
73
Elicitar reaes do tipo sim, mas passivo, ativo ou interativo identifica atores, explica o que acontece a eles e descreve como acontece mais eficazes se o projeto tiver contedo inovador ou desconhecido tipo rascunho, fceis de modificar
princpio da negao construda)
74
Prottipos
Vantagens:
barato amigvel, informal e interativo fornece uma crtica das interfaces do sistema cedo no desenvolvimento fcil de criar e modificar
75
Verificao
Fonte Julio Cesar Leite
Estamos construdo o produto de maneira correta? Acontece com a utilizao de conhecimento empacotado. Pouca nfase na verificao Escolher a sub-diviso em que se vai trabalhar Antecipar os recursos e atores do UdI necessrios para levar a cabo a tarefa.
76
Inspees
criadas em 1972 por Fagan, na IBM, para melhoria da qualidade de cdigo hoje so utilizadas em qualquer tipo de artefato gerado pelo processo de desenvolvimento inspeo pode detectar de 30% a 90% dos erros existentes tcnica de leitura aplicvel a um artefato, buscando a localizao de erros ou defeitos no mesmo, segundo um critrio prestabelecido
77
Inspees em Requisitos
Planejamento
Viso geral
Deteco
Coleo
Correo
Acompanhamento
Processo
Autor
Secretrio Relator
Papis
Inspeo
Tcnicas de leitura
Artefatos
78 Laitenberger01
Inspees em Requisitos
Inspees baseadas em check lists:
Inspetores utilizam uma lista com os itens a serem verificados cada artefato tem uma lista especfica (Documento de Requisitos, Casos de Uso, Glossrios, Lxico Ampliado da Linguagem...) os defeitos so anotados no artefato sendo analisado aps a reviso, realizada uma reunio onde os problemas encontrados so relatados aos desenvolvedores
79
Checklist
Fonte Julio Cesar Leite
Pontos a serem avaliados/observados durante o processo de inspeo Depende do material a ser inspecionado (casos de uso, cenrios, DFDs, JSD...) Depende do enfoque da inspeo Taxonomia dos defeitos - o que procurar
80
Exemplo OO
Checklist OO:
Todas as classes so representadas por retngulos com 1,2 ou 3 compartimentos? As classes possuem nomes diferentes? Existem classes sem relacionamentos definidos? Os atributos e os mtodos de cada classe so adequados aquela classe? Todo comportamento especificado possvel de ser contemplado atravs das associaes do modelo?
81
Gerncia de Requisitos
82
Gerncia de Requisitos
83
Gerncia de Requisitos
Gerenciar requisitos a tarefa de garantir que as solicitaes dos clientes estejam sendo atendidas pelo processo de produo do software Para isso torna-se de fundamental importncia que estas solicitaes estejam relacionadas com os produtos de software (requirements allocation)
84
O que escopo?
ESCOPO
TEMPO data de entrega
85
Controlando o escopo
Sndrome do j que Caper Jones reporta que os requisitos que rastejam para debaixodo escopo so representam
risco de 80% a projetos de gerncia de informao risco de 70% a projetos militares
86
Controlando o escopo
Requisitos rastejantes
nova funcionalidade modificaes
requisitos aumento do escopo
Diga NO !!!
87
Otimizao (5)
Foco na melhoria de processo
Gerenciado (4)
Processo medido e controlado
Definido (3)
Processo caracterizado, completamente bem entendido
Repetvel (2)
Pode repetir tarefas previamente dominadas
Inicial (1)
Imprevisvel e pouco controlado
O processo informal 88
Estrutura do CMM
Fonte SEI Mark Paulk
Contm
Key process areas So organizadas por
Atingem
Common features Contm
Metas Levam a
Implementao ou institucionalizao
Atividades ou infra-estrutura
89
Prticas Chave
Descrevem o que ser feito para cada rea-Chave do Processo, mas no como
So requisitos a serem atendidos
90
Identificar requisitos incompletos ou ausentes Determinar se os requisitos esto claros, possveis de serem implementados, consistentes e verificveis Revisar requisitos com problemas potenciais Negociar compromissos com os grupos envolvidos
91
Atividades II
92
Atividades III
Revisar com a gerncia snior alteraes nos compromissos feitos com grupos externos. As alteraes de compromissos feitos dentro da organizao so negociadas com os grupos envolvidos.
93
Mudanas
inesperado
94
Mudanas
Fonte Julio Cesar Leite
Real
Desejado
- Identificadas - Avaliadas - Avaliadas sob o ponto de vista de risco - Documentadas - Planejadas Comunicadas aos grupos e indivduos envolvidos - Acompanhadas at a finalizao
96
97
98
http://stones.les.inf.puc-rio.br/karin/exemplo/index.html
Evoluo
Fonte Julio Cesar Leite
99
100
Porque priorizar?
Fonte Julio Cesar Leite
Controlar o escopo do projeto: Sndrome do j que Caper Jones reporta que os requisitos que rastejam para debaixodo escopo representam
risco de 80% a projetos de gerncia de informao risco de 70% a projetos militares
101
Tcnicas de priorizao
Fonte Julio Cesar Leite
Formais
QFD
Informais
R$ 100 Categorizar
102
Kovitz 1999
3 - dever ser implementado de modo perfeito 2 - precisa funcionar, mas no de modo espetacular 1 - pode conter bugs
condicional
melhoraria produto, mas no o tornaria inaceitvel se ausente
opcional
classe de funcionalidade que pode ou no valer a pena
104
tambm chamado rastreamento, porque deve permitir a navegabilidade dos produtos de software, a incluindo os requisitos, em relao as solicitaes dos clientes.
105
tcnica usada para prover relacionamento entre requisitos, projeto e implementao final do sistema;
uma caracterstica de sistemas nos quais os requisitos so claramente ligados s suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento do sistema;
106
Referncias
www.inf.puc-rio.br/~karin/pos - pgina do curso de Engenharia de Requisitos Davis, A. "Software Requirements: Objects, Functions, & States", 2nd edition, Prentice Hall, 1993 Jacobson, Booch, Rumbaugh "Unified Software Development Process". Reading, Mass.: Addison-Wesley, c1999. Jackson, M. - Software Requirements & Specifications : A Lexicon of Practice, Principles and Prejudices (July 1995) Addison-Wesley Pub Co; Kotonya, G. & Sommerville, I. "Requirements engineering: processes and techniques". Chichester: Wiley, 1998. Laitenberger, O. "A Survey of Software Inspection Technologies". Handbook on Software Engineering and Knowledge Engineering, vol. II, World Scientific Pub. Co, 2001.
107
Referncias
Leffingwell, D; Widrig, D. - Managing Software Requirements: A Unified Approach (The Addison-Wesley Object Technology Series) - Addison-Wesley Pub Co - November 1999 Leite, J.C.S.; "Engenharia de Requisitos". Notas de aula, DI/PUC-Rio. Pdua F.,W. P. "Engenharia de Software: Fundamentos, Mtodos e Padres". Ramesh, B. & Jarke, M., "Towards reference Models for Requirements Traceability", IEEE Trans. Software Eng., vol. 27, no. 1, pp. 58-93, Jan. 2001. Robertson, S.; Robertson, J. - Mastering the Requirements Process Addison-Wesley Pub Co - May 4, 2000 Young, Ralph - effective requirements practices Addison Wesley Information Technology Series
108
Referncias
Sayo, M.; Leite, J.C.S.P. "Rastreabilidade". srie Monografias em Cincia da Computao. DI/PUC-Rio, a ser publicado. Sommerville, I. "Software engineering". (4th ed.), Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1993 SWEBOK: Software Engineering Body of Knowledge, chapter 2. IEEE. Disponvel em http://www.swebok.org. Weber, K. "Projeto Melhoria de Processo de Software Brasileiro". Palestra proferida no III Simpsio Brasileiro de Qualidade de Software - SBQS 2004, Braslia, DF. Wiegers, K. "The seven deadly sins of software reviews". Software Development -6(3), 1998. pp.44-47 Wiegers, K. "Peer Review Process Description". Disponvel em http://www.processimpact.com/pr_goodies.shtml.
109