Engenharia de Requisitos

Engenharia de Requisitos
Prof. Carla A. Lima Reis

clima@ufpa.br
Engenharia de Software I - 2006
http://www.cultura.ufpa.br/clima
2006
1
Fonte: Pressman. Captulo 11 Shari Pleeger. Captulo 4 Leitura recomendada: Explorando Requerimentos de Sistemas Weinberg Gerncia de Requisitos - Miriam Sayo e Karin Koogan Breitman Requirements Engineering: A Roadmap
2
Objetivo
Descrever em maior detalhe as preocupaes relacionadas com os requisitos de software
Organizao
Organizao
Introduo Requisitos de Software Gerncia de Requisitos Anlise de Requisitos Princpios de Anlise
Afinal, o que so requisitos?

Clientes
Requisitos de Software
Usurios Necessidades Limitaes Impossibilidades
Infra Estrutura Tecnolgica

6
Requisitos devem ser bem definidos durante o desenvolvimento do software, a fim de atender as necessidades dos clientes. Requisitos mal definidos, ou que no atendam as expectativas dos clientes, exigem reparos durante o projeto de software. A manuteno do projeto de software eleva drasticamente seus custos, podendo lev-lo ao fracasso.
7
Origem de todos os problemas e SOLUES
Custo da Correo
Custo aumenta com o tempo de descoberta do erro

Custo de reparo Custo de perda de oportunidades Custo de perda de clientes
Engenharia de sistemas Anlise de Requisitos de software Projeto de software
O custo de 1 problema 100 vezes maior se reparado aps a ap implantao. implanta o. Os erros mais caros so aqueles cometidos na Anlise de requisitos An e descobertos pelo usurio! usu rio!
10
Definies para Requisitos: Uma capacidade de software que deve ser disponibilizada por um sistema ou componente de sistema de modo a satisfazer um contrato, padro, especificao ou outra formalidade imposta. [Dorfmam 90] uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar para atingir seus objetivos
11
Requisitos Descrevem: Uma facilidade encontrada no nvel do usurio. Uma propriedade geral do sistema . Uma restrio do sistema. Uma restrio ao desenvolvimento do sistema.
12
Existe restrio ambiental? Tipos de requisitos : Comunicao com outros Ambiente fsico sistemas/ formatao dos dados Interfaces Tipos de usurios, Usurios e fatores humanos facilidades, etc Funcionalidade O que o sistema ir fazer? Documentao Qual a documentao necessria? Dados Formato dos dados, preciso, persistncia, etc. Recursos Material, pessoal, habilidades, Segurana cronograma, custo Garantia de qualidade Acesso, backup, outros danos Tempo entre falhas, nvel de defeitos, etc.
13
Categorias de Requisitos
Requisitos Funcionais
RF so requisitos diretamente ligados a funcionalidade do software.
Onde o sistema funcionar?
Requisitos No Funcionais
RNF so requisitos que expressam restries que restri o software deve atender ou qualidades especficas espec que o software deve ter. ter.
Requisitos-1 (Requisitos Inversos)

RIN estabelecem condies que nunca podem condi ocorrer. ocorrer.
14
Categorias de Requisitos: 1) Requisitos Funcionais (RF)
Engenharia de Software I - 2006 Engenharia de Software I - 2006
Categorias de Requisitos: 1) Requisitos Funcionais (RF)
Definem os servios que devem ser fornecidos pelo sistema, como ele deve reagir aos tipos entradas e como responder em situaes particulares. "uma ao que o produto deve ser capaz de realizar" [Robertson05]
16
Descrevem funcionalidades ou servios do sistema. Diretamente ligados funcionalidade do software, o que o sistema deve prover. Depende do tipo do sistema, expectativas do usurio e o contexto em qual o software est inserido.
15
Categorias de Requisitos: 1) Requisitos Funcionais (RF) Exemplos:

Categorias de Requisitos:
2) Requisitos No-Funcionais (RFN)
O sistema deve emitir um recibo aps cada transao de compra. O sistema deve prover um formulrio de entrada para a formul entrada dos resultados dos testes clnicos de um paciente. cl paciente. De acordo com o perfil e retries do usurio,o sistema fornece retri usu tipo de vises apropriados para a leitura de um documento da base de dados. Cada registro deve possuir um identificador unico, permitindo o unico, acesso do usurio aos registros em uma base de dados. usu
17
So requisitos que expressam restries que o software deve atender ou qualidades especficas que o software deve ter. Definem propriedades do sistema ou restries como: confiabilidade, tempo de resposta, requisitos de armazenamento, restries de dispositivos I/O etc. Requisitos de processo tambm podem ser especificados, como linguagem de programao ou mtodo de desenvolvimento.
18
Propostos pela IEEE: Usabilidade, Confiabilidade, Eficincia, Manutenibilidade, Portabilidade. Requisitos No-Funcionais podem ser mais crticos que os Requisitos Funcionais. Se no forem bem definidos podem tornar o sistema inutilizavel. "uma qualidade que o produto deve possuir." [Robertson05]
Classificaes
Requisitos de Produto Requisitos que especificam como o produto deve se comportar. Ex.: Tempo de execuo, confiabilidade etc. Requisitos Organizacionais Requisitos que so conseqncias das politicas e normas estabelecidas pela organizao. Ex: Padres de processo usados, requisitos e padres de implementao.
20
19
Classificaes
Exemplos
Requisitos Externos Requisitos que provm de fatores que so externos ao sistema e a seu processo do desenvolvimento. Ex.: Tempo de execuo, confiabilidade etc.
Requisitos de Produto O sistema deve possibilitar a comunicao necessria
entre o APSE e o usurio, atrves da codificao padro de caracteres da linguagem de programao Ada. do sistema e a elaborao de documentos deve estar de acordo os processo e padres definidos em XYZCo-SP-STAN-95 XYZCo- SP- STAN-
Requisitos Organizacionais O processo de desenvolvimento
21
22
Exemplos
Taxonomia
Requisitos de Processo
Requisitos no funcionais
Requisitos de Produto
Requisitos Externos
Requisitos Externos O sistema no divulgar nenhuma informao pessoal
sobre clientes, a no ser nome e o cdigo de operao do sistema.
requisitos de requisitos de requisitos de requisitos de eficincia confiabilidade portabilidade usabilidade
requisitos de entrega
requisitos de requisitos para implementao padres
requisitos legais
requisitos de custo
requisitos de interoperabilidade
Sommerville 92
requisitos de performance
requisitos de espao
24
23
Categorias de Requisitos: 3) Requisitos Inversos (RIN) So requisitos que definem estados e situaes que nunca devem ocorrer.
Requisitos
Clientes
RF Usurios
Necessidades Limitaes Impossibilidades RNF RIN Infra Estrutura Tecnolgica

26
Ex.: O sistema no pode deixar que a temperatura da caldeira ultrapasse 100C.
RNF
25
Mais Exemplos
O sistema deve prover um formulrio de entrada formul para a entrada dos resultados dos testes clnicos cl de um paciente. (RF) paciente. Dependendo do resultado do teste, somente o teste, Supervisor pode efetuar a entrada do resultado do teste de um paciente. (RNF de confidencialidade). paciente. confidencialidade). O sistema deve emitir um recibo para o cliente, cliente, com o tempo mximo de 8 segundos aps a ap transao. (RF , RNF de performace). transa o. performace). O sistema no pode apagar informao de um informa cliente (RIN).
27
Requisitos Funcionas X Requisitos No Funcionais
Funcional: descreve uma interao entre o intera sistema e seu ambiente. Exemplos: o sistema dever ter comunicao com um comunica sistema x externo. Quais estados devem ser encontrados para uma mensagem ser enviada. No-funcional: Nodescreve uma restrio do restri sistema que limita nossas opes para criar uma op soluo para o problema. solu Exemplos: Contracheques distribudos em no distribu mais que quatro horas depois de os dados iniciais terem sido lidos.
28
Definio e Especificao Definio dos requisitos Listagem completa de tudo que o cliente espera que o sistema proposto faa. Especificao dos requisitos Redefine os requisitos em termos tcnicos apropriados para o desenvolvimento do projeto do sistema.
29
Definio e Especificao Exemplo: Defini Especifica Definio de Requisito Defini
Especificao de Requisitos Especifica
O software deve fornecer meios de representao e representa acesso a arquivos externos criados por outras ferramentas. O usurio deve definir os tipos de arquivos externos. usu Cada tipo de arquivo externo deve estar associado a ferramenta que o utiliza. Cada tipo de arquivo externo deve ser representado por um cone especifico no display do usurio. usu O sistema deve fornecer cones para representados tipos de arquivo externo definidos pelo usurio. usu Quando um usurio define um cone para representar um usu arquivo externo o efeito desta seleo aplicado a sele ferramenta associada com o tipo de arquivo externo e com o cone que o representa
30
Requisitos inverificveis :Algumas palavras levam a requisitos inverific impossveis de serem verificados
Palavras no Verificveis Verific Engenharia de Software I - 2006 Amigvel Amig Possveis substitutos Poss Engenharia de Software I - 2006 Nmero mximo de passos Lista de funcionalidades presentes em outras aplicaes aplica Menus ou prompts para auxiliar usurios usu Dimenses Requisitos mnimos de hardware Sistemas operacionais em que deve funcionar Dimenses aceitveis (em nmero de Bytes) aceit Variveis que podem acomodar uma gama de mudanas Vari mudan de valores Funes que implementam uma de vrias possibilidades Fun
Requisitos no funcionais devem ser elaborados at que se tornem verificveis
Requisito Inverificvel Inverific

O banco de dados ZZ deve ser flexvel flex vel MNOP deve ser seguro seguro
Requisito Verificvel Verific

O banco de dados ZZ deve possuir oito campos por registro. registro.
Portvel Port
Pequeno Flexvel Flex
MNOP deve parar sua operao se uma opera 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 37 MNOP deve estar dentro dos padres estabelecidos pela norma N567 seo 3.6 para se temperaturas de superfcies externas. superf externas. O sistema CE deve escanear os dados do usurio e conta de cada folheto de depsito usu dep em 2 segundos ou menos menos
31
O sistema CE deve processar depsitos rapidamente dep rapidamente
32
Medidas de Requisitos
Propriedade Medidas possveis poss
Caractersticas dos requisitos Esto corretos? So consistentes? Esto completos? So realistas? Cada requisito descreve algo necessrio ao cliente? Podem ser verificados? Podem ser rastreados?
34
Velocidade
Processamento de transaes/segundo transa Tempo de resposta usurio/evento usu Tempo de atualizao do display atualiza K bytes Capadidade de memria Ram mem Tempo de treinamento Nmero de pginas de ajuda p Tempo mdia a falha m Taxa de ocorrncia de falha Probabilidade de indisponibilidade do sistema Tempo para reiniciar aps uma falha ap Porcentagem de eventos que podem causar falhas Probabilidade de corrupo de dados em caso de falhas corrup Nmero de sistemas portveis port
33
Tamanho Usabilidade
Confiabilidade
Robustez Portabilidade
Introduo Engenharia de Requisitos Engenharia de Requisitos Introduo

O que ? o processo de estabelecer quais so os servios requeridos pelo usurio de um sistema e as restries para seu uso e desenvolvimento. Requisitos so obtidos atravs de uma atividade de comunicao, posteriormente analisados, formalmente documentados , e subsequentemente implementados.
36
35
Introduo
Importncia Requisitos constituem a base para a definio da arquitetura do sistema, para a implementao propriamente dita, para gerao dos casos de testes e para validao do sistema junto ao usurio.
37
Engenharia de Requisitos
Tanto o desenvolvedor quanto o cliente assumem um papel ativo na engenharia de requisitos de software (conjunto de atividades freqentemente referido como anlise)
Cliente: tenta formular uma descrio, s vezes descri nebulosa, em nvel de sistema dos dados, funo n fun e comportamento Desenvolvedor: age como inquisitor, consultor, inquisitor, solucionador de problemas e negociador
38
Introduo
Introduo Engenharia de Requisitos

Anlise e especificao de requisitos pode parecer tarefa simples. Entretanto,
Introduo Engenharia de Requisitos

Quais so os problemas reais?
O cliente possui apenas uma vaga idia do que id realmente quer O desenvolvedor fica ansioso para prosseguir com a vaga idia com a inteno de encontrar id ia inten os detalhes durante o restante do processo processo O cliente modifica continuamente os requisitos O desenvolvedor sofre com as mudanas, as mudan quais levam a erros de especificao e especifica programao programa
E o processo continua...
40
O contedo da comunicao muito grande conte comunica Grande chance de m interpretao e m m interpreta m informao informa Cliente: Eu sei que voc acredita que entendeu o que pensa que eu disse, mas no estou certo de que voc reconhece que o que voc ouviu no o que eu quis dizer dizer
39
Engenharia de Requisitos Introduo

Definio para Eng. de Requisitos:
o uso sistemtico de princpios, tcnicas e sistem princ t ferramentas comprovadas para a anlise, an documentao, evoluo continuada das documenta evolu necessidades do usurio e especificao do usu especifica comportamento externo de um sistema para satisfazer as necessidades do usurio que sejam usu efetivas em termos de custo. Note que como em todas as disciplinas de engenharia, a engenharia de requisitos no conduzida de um modo espordico, aleatrio ou sujeito a azares, mas, espor aleat ao contrrio, o uso sistemtico de abordagens contr sistem comprovadas. - Donald Reifer 1994 comprovadas.
41

Definio para Eng. de Requisitos: Engenharia de Requisitos pode ser definida como o processo sistemtico de desenvolvimento de requisitos atravs de um processo cooperativo de anlise onde os resultados das observaes so codificados em uma variedade de formatos e a acurcia das observaes constantemente verificada. Klaus Pohl
42

A Engenharia de Requisitos (ER) uma sub-rea da Engenharia de Software que estuda o processo de produo e gerncia dos requisitos que o software dever atender. Trabalha junto aos clientes durante a fase de elicitao ou levantamento dos requisitos e perpassa todas as fases do processo de desenvolvimento do software.
43

Fornece mtodos, tcnicas e ferramentas que forneam suporte adequado s tarefas de produo e gerncia dos requisitos do sistema.
A Engenharia de Requisitos foi estabelecida como disciplina independente em 1993, quando da criao do IEEE International Symposyum on Requirements Engineering (RE93).
44

Por que Engenharia de Requisitos???

A Engenharia de Requisitos engloba os processos de produo e gerncia de requisitos.
45
46

Processo de Produo de Requisitos:

Processo de Produo de Requisitos: Ian Sommerville, quatro etapas
Elicitao Registro
Captura de requisitos, comunicao com clientes, aquisio de referncias. Codificao, modelagem, utilizando-se algum tipo de representao persistente que garanta o acesso posterior aos requisitos e suas origens. Validao e verificao de modo a garantir que a acurcia das observaes e informaes levantadas durante o processo.
Elicitao, anlise e negociao e validao
Julio Cesar Sampaio do Prado Leite, etapas essencias:

Elicitao, modelagem e anlise (validao e verificao)
Karl Wiegers, adiciona uma quarta etapa
Qualidade
Especificao, que foca na documentao de informao relativa a rastreabilidade dos requisitos.

48
47

Processo Essencial:
Entender o problema ELICITAO Utilizar tcnicas para elicitar os requisitos: questionrios, entrevistas, documentos... Modelar o problema MODELAGEM Representar nosso entendimento do problemas utilizando tcnicas para modelagem: DFD, MER, casos de uso... Analisar o problema ANLISE Verificar e Validar a informao capturada

Processo
Anlise Elicitao Modelagem V&V
49
50
Mundo Real
Elicitao
Inspirao: Guilherme Nicodemos -UCP
Elicitao
Solues
Problemas
Identificar as fontes de informao Coleta de fatos

Gap Semntico
Mundo Computacional
Elicitao de Requisitos
51
52
Identificao de Fontes de Informao

Atores do Universo de Informaes
Quem est relacionado ao software?

no clientes
Clientes Usurios Desenvolvedores
usurios fregueses interessados clientes
clientes cliente terceirizados investidor dono especialista contratado parceiro
Documentos Livros Sistemas de Software COTS

53
desenvolvedores
CQ escritores tcnicos engenheiros de software

54
Heursticas para identificao de fontes de informao

Coleta de Fatos
Leitura de documentos Observao Observa Entrevistas Reunies Questionrios Question Antropologia Participao ativa dos atores Participa Bases de Requisitos no funcionais Engenharia Reversa Reutilizao Reutiliza
56
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)? Quais so os documentos mais referenciados pelos atores do Udl?
55
Conhecimento Tcito
aquele conhecimento que trivial para o entrevistado e no o para o entrevistador Por ser trivial nunca lembrado como importante e, portanto, no transmitido ao entrevistador, que, no sabendo, no pode perguntar
57
Elicitao
Perguntar porqu?
A cafeteira deve ser feita de ao qual a razo disto? pode me explicar porqu? qual o pensamento atrs disto?
Ian Alexander, Writing better requirements
58
Elicitao
Porque se for de vidro pode quebrar
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 porque poderiam ser utilizadas nesta situao? situa o? Quais seriam os reais requisitos? reais requisitos?
Dica: Separar requisito de soluo/implementao Dica: solu o/implementa
Requisito real A cafeteira deve ser feita de material inquebrvel

Plstico Pl Poliuretano At mesmo ao At
Ian Alexander, Writing better requirements
59
60
Observao
Os usurios misturam a soluo com os requisitos
Entrevistas
+
contato direto com atores possibilidade de validao imediata
Separar NECESSIDADE da soluo proposta ou atual!
conhecimento tcito diferenas culturais
61
62
Reunies
Extenso da entrevista Brainstorm JAD Workshop de Requisitos
Reunies
+
dispor de mltiplas opinies criao coletiva
disperso custo
63
64
Observao
+ baixo custo pouca complexidade da tarefa
Exerccio de Elicitao
Documentos do domnio dom a) o projeto de um banco de dados que mantm o mant histrico de desempenho dos projetos.b) vai permitir hist projetos.b) que usurios acessem cronogramas originais e c) usu compar-los com projetos atuais. d) O sistema deve ser compar atuais. fcil de usar pelos gerentes e e) acessvel de qualquer acess mquina na intranet. f) O sistema deve ser implementado em Oracle e g) ter boa performance. h) o sistema deve produzir um relatrio de progresso de relat todos os projetos para o gerente geral mensalmente. i) a mensalmente. tela deve mostrar as tendncias das datas previstas versus marcos atingidos e j) prever as datas provveis prov de trmino dos projetos. k) O sistema deve estar . projetos implementado em Dezembro de 2004 e l) ser ser desenvolvido pela Informtica e m) e controlado pela Inform Gerncia de Informao. n) O software deve rodar em Informa o. PCs. 66
dependncia do ator (observador) observador) superficialidade decorrente da pouca exposio ao exposi universo de informaes informa
65
Elicitao
Para as frases a n classificar em:
Leitura de Documentos
+
facilidade de acesso s fontes de informao informa volume de informao informa
Requisitos do usurio: Requisitos do sistema: Elementos de projeto \ planejamento):
disperso das informaes informa volume de trabalho requerido para identificao identifica dos fatos
67
68
Questionrios
Qualitativo Quantitativo O que perguntar
exige conhecimento mnimo similar a entrevista estruturada
Exemplos
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
69
Num. de Respostas
70
Exemplos
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)
Exemplos
Qualitativo
O qu voc acha da sua formao no que se forma refere a produo de software de qualidade? O produ que voc acredita ser necessrio para necess aprimorar seu desempenho? Que conhecimentos voc desejaria adquirir? Por qu? Objetivo: verificar a opinio em relao a rela poltica de treinamento pol Justificativa: uma organizao madura tem organiza polticas bem definidas de treinamento. pol Pergunta de controle
72
Num. de Respostas
71
Controle
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)
Questionrios
+
padronizao de perguntas tratamento estatstico
Num. de Respostas
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
limitao das respostas pouca interao/participao
3. Como voc classifica o treinamento existente na XXX em gerncia de configurao?

60 55 50 45 40 35 30 25 20 15 10 5 0 N/A Inexistente Espordico Bom Muito bom
Num. de Respostas
73
74
Bases de Requisitos nofuncionais

Taxonomias propostas na literatura Servem de guia para a elicitao
Base de RNFs Elicitao
utilidade como-
Taxonomia
Portabilidade Independncia Auto conteno Confiabilidade Eficincia Engenharia Humana Preciso Completeza Integridade/Robustez Consistncia Responsabilidade Testabilidade manutenibilidade Compreensiblidade Comunicao Modifiabilidade Auto descrio Estrutura Conciso Legibilidade Eficincia de dispositivo Acessabilidade
Utilidade geral
Boehm 76
Aumentabilidade
76
75
Mundo Real
Modelagem
Mundo Computacional
Modelar
Para que servem modelos?
Representao Representa Organizao Organiza Armazenamento Comunicao Comunica
Solues
Problemas Gap Semntico
Modelagem dos Requisitos
77
78
Sentenas de Requisitos
O sistema deve + [verbo + objeto | frase verbal ] + [complemento de agente | nulo] + [condies | nulo] [condi Trs classes de sentenas: {Entrada, Sada, Mudana de senten Sa Mudan 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 identifica 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 institui f software As sentenas podem ser de trs tipos: funcionais, nosenten nofuncionais e inversas.
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 m segundos. O sistema deve cadastrar o cliente, desde que o cliente possua identificao. identifica O sistema deve transformar uma fita disponvel em fita dispon emprestada, quando a fita for alugada pelo cliente. O sistema deve cadastrar bibliotecrios. bibliotec O sistema deve verificar a identidade do bibliotecrio. bibliotec 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. usu
79
80
Atributos de uma boa especificao

Clareza ! Ambgua Completa Simples Bem escrita
Clareza
Um requisito claro
Tipo de usurio usu Resultado desejado O engenheiro de teste teste simula simula erros de componente . utilizando as funes de teste QQ e TT. fun Objeto Condies Condi
Um requisito vago
Em geral o sistema sistema Precisa ou no? no? Quais? Quais? Como verificar isto? isto? deve ser capaz capaz de diagnosticar possveis erros poss erros em um prazo razovel. razo vel.
81
82
Ambiguidade
O sistema deve enviar relatrios de produtividade relat dos programadores, analistas ou desenvolvedores do programadores, projeto mensalmente ou quando requisitado. requisitado.
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)
84
"Realizar rotina de importao de dados peridica de importa peri preo de fluido pre fluido "Identificar e associar as intervenes que so interven complementares s outras" O sistema deve emitir uma mensagem de ateno aten visual ou auditiva no evento de falha do sistema de refrigerao. refrigera o.
83
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
Requisitos com alternativas

Mas, com exceo, apesar, quando
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.
86
85
Requisitos mal escritos

(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
87
Qualidade
7 Pecados [Myers]
Informaes irrelevantes Incompleteza
Excesso de Especificao ( decises de desenho) Inconsistncia Ambiguidade Referncia futura Requisitos que no podem ser testados
88
Mundo Computacional
Mundo Real
Anlise
Anlise
Problemas Gap Semntico
Solues
Anlise de Requisitos
90
89
Verificao X Validao
Verificao
estamos construindo o produto de maneira certa? certa? (em relao a outros rela produtos) produtos)
Validao atravs de Prottipos

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)
92
Validao
estamos construindo o produto certo? certo? (em relao a inteno rela inten dos fregueses) fregueses)
entre modelos
entre o UdI e um modelo
91
Prottipos
Vantagens:
Tcnicas informais
Leitura ad hoc
barato amigvel, informal e interativo fornece uma crtica das interfaces do sistema cedo no desenvolvimento fcil de criar e modificar
Walkthroughs
Inspees
93
94
Leitura ad hoc
baseada na experincia e conhecimento do inspetor aspectos que podem ser verificados:
clareza (os requisitos esto bem determinados?) completude (esto presentes todos os requisitos necessrios necess especificao do sistema?) especifica consistncia (requisitos consistentes com a viso geral do sistema?) sistema?) corretude (os requisitos descrevem as funcionalidades de maneira correta?) funcionalidade (funcionalidades descritas so necessrias e suficientes necess para atingir os objetivos do sistema?) testabilidade (as funcionalidades permitem a verificao ou teste de verifica forma a mostrar que os requisitos so satisfeitos?) detalhamento (o nvel de detalhe nos requisitos suficiente para n fornecer uma base adequada ao desenho do sistema?).
95
(reviso de apresentao)
autor seleciona participantes e estabelece objetivos Preparao ad hoc Reunio (autor(es), avaliador(es), secretrio(s)) Leitura
autor l avaliadores escutam, apontam problemas e sugerem alteraes altera secretrio(s) anotam problemas secret
Walkthrough
Lista de problemas
96
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
97
Gerncia de Requisitos
98
Porque Gerenciar Requisitos?
Quanto mais tarde um erro detectado, maior o detectado, custo de corrigi-lo. corrigiMuitos erros so realizados durante a elicitao e elicita definio de requisitos defini Muitos erros nos requisitos podem ser detectados cedo no ciclo de desenvolvimento. desenvolvimento. Erros tpicos incluem fatos incorretos, omisses, incorretos, omisses, inconsistncias e ambiguidade. ambiguidade. Erros nos requisitos constituem uma das maiores preocupaes da indstria de software. preocupa ind
No desenvolvimento de um software natural que sejam encontrados novos requisitos, ou que ocorra mudanas nos j estabelecidos. Conhecido como Evoluo dos Sistemas, resultado de mudanas no meio ambiente
onde o prprio sistema de software est inserido. Se o macrosistema muda os sistemas de software devem acompanhar esta mudana ou ficaro cada vez menos teis [Lehman96].
99
100
O processo de mudana dos requisitos precisa ser controlado. O impacto destas mudanas precisa ser avaliado e compreendido de modo que sua implementao seja feita de maneira eficiente e a baixo custo. Este processo conhecido como a gerncia de requisitos.
101
elicitar requisitos implementar rastreabilidade Requisitos
modelar requisitos
gerenciar evoluo
validar requisitos
102
abordagem sistemtica para:
Definio para Gerncia de Requisitos: Enfoque sistemtico para a elicitao,
organizao e documentao dos requisitos do sistema e um processo que estabelece e mantm o acordo entre usurios e a equipe de projeto medida que os requisitos se modificam
[Leffingwell00].
elicitar, modelar e analisar requisitos; documentar e controlar requisitos; acompanhar mudanas em requisitos; implementar a rastreabilidade (para apoiar as atividades de gerenciamento de projeto)
103
104
Porqu difcil? 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
105
Segundo Ian Sommerville, aspectos da Gerncia de Requisitos: 1. Gerenciar as mudanas em requisitos existentes (pertencentes a especificao), 2. Gerenciar o relacionamento entre os requisitos, 3. Gerenciar as dependncias entre o documento de requisitos e outros documentos produzidos durante o desenvolvimento de software.
106
necessrio, definir um conjunto polticas. necessrio definir um conjunto objetivos para o processo de gerncia. de de
Polticas bem definidas para a gerncia de configurao, controle de mudanas e rastreabilidade e garantia da qualidade precisam colocadas em prtica de modo a viabilizar um processo dinmico e eficaz de gerncia de requisitos.
Objetivos claros e transmitidos para todos os integrantes da equipe.
Os artefatos (documentos) produzidos durante o desenvolvimento do software devem tornar a gerncia dos requisitos visvel e transparente.
Estes devem seguir padres externos corporativos, a fim de manter uniformidade. e
107
108
Rastreabilidade
Conjunto de ligaes entre as fontes dos requisitos, os requisitos propriamente ditos e outros artefatos. Fontes de Requisitos podem ser clientes, necessidades de usurios, documentos da organizao, padres a serem seguidos ou legislao. (pr-rastreabilidade). Os artefatos, produtos desenvolvidos a partir dos requisitos, esto diretamente relacionados ao contexto tcnico de desenvolvimento. (psrastreabilidade).
109
Rastreabilidade
Pr-rastreabilidade
Engenharia de Software I - 2006 Necessidade dos cliente e documentos Requisitos
Ps-rastreabilidade
Artefatos de designer e implementao
110
Rastreabilidade
Rastreabilidade elos
Pr-Rastreabilidade
Ps-Rastreabilidade
As ligaes associadas ps-rastreabilidade permitem identificar quais componentes implementam um determinado requisito, e tambm possibilitam saber claramente, dado um artefato, quais os requisitos que ele deve atender.
111
As ligaes associadas pr-rastreabilidade permitem identificar a origem de cada requisito e tambm quais os requisitos originados de uma determinada fonte, como por exemplo, os requisitos originados de padres organizacionais.
112
Tipos de elos de Rastreabilidade Fontes: documentos que remetem origem dos requisitos (normas, padres, legislao pertinente, atas de reunies, ....); Stakeholders: so as pessoas envolvidas no Processo de Requisitos e que tambm possuem algum grau de interesse na rastreabilidade; Objetos ou artefatos: correspondem a objetos conceituais relacionados ao produto ou a artefatos gerados pelo processo de desenvolvimento.
113
Rastreabilidade na Prtica A matriz de rastreabilidade pode ser implementada com uso de uma ferramenta de uso geral, como um editor de textos ou uma planilha eletrnica.
114
Rastreabilidade na Prtica
Matriz de Rastreabilidade entre requisitos e entidades geradas no processo de desenvolvimento
Rastreabilidade na Prtica
Matriz de Rastreabilidade entre requisitos funcionais e no funcionais
115
116
Rastreabilidade na Prtica Ferramentas
Requisite Pro
IBM/Rational Requisitepro Controla
117
118
Requisite Pro
Requisite Pro
119
120
Estrutural (dados)
Comportamental (estados e eventos)
Vises para um problema (aspectos fundamentais do software)
[FOWLER96] Arquitetural (operaes)

121

Engenharia de Requisitos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Engenharia de Requisitos

Uploaded by

Copyright:

Available Formats

Engenharia de Requisitos

Prof. Carla A. Lima Reis

Engenharia de Software I - 2006

Introduo Requisitos de Software Gerncia de Requisitos Anlise de Requisitos Princpios de Anlise

Afinal, o que so requisitos?

Usurios Necessidades Limitaes Impossibilidades

Infra Estrutura Tecnolgica

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Custo aumenta com o tempo de descoberta do erro

Engenharia de Software I - 2006

Engenharia de sistemas Anlise de Requisitos de software Projeto de software

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Onde o sistema funcionar?

Engenharia de Software I - 2006

Requisitos-1 (Requisitos Inversos)

Requisitos de Produto O sistema deve possibilitar a comunicao necessria

Requisitos Organizacionais O processo de desenvolvimento

Requisitos Externos O sistema no divulgar nenhuma informao pessoal

Engenharia de Software I - 2006

sobre clientes, a no ser nome e o cdigo de operao do sistema.

requisitos de requisitos de requisitos de requisitos de eficincia confiabilidade portabilidade usabilidade

requisitos de requisitos para implementao padres

Engenharia de Software I - 2006

Necessidades Limitaes Impossibilidades RNF RIN Infra Estrutura Tecnolgica

Ex.: O sistema no pode deixar que a temperatura da caldeira ultrapasse 100C.

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Especificao de Requisitos Especifica

Requisito Inverificvel Inverific

Requisito Verificvel Verific

Pequeno Flexvel Flex

O sistema CE deve processar depsitos rapidamente dep rapidamente

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Introduo Engenharia de Requisitos Engenharia de Requisitos Introduo

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Introduo Engenharia de Requisitos

Engenharia de Software I - 2006

Introduo Engenharia de Requisitos