Anda di halaman 1dari 31

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
Engenharia de Software I - 2006

Engenharia de Software I - 2006

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

Afinal, o que so requisitos?


Clientes

Requisitos de Software
Engenharia de Software I - 2006

Usurios Necessidades Limitaes Impossibilidades

Infra Estrutura Tecnolgica


6

Requisitos de Software
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

Requisitos de Software
Origem de todos os problemas e SOLUES

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Requisitos de Software
Custo da Correo
Engenharia de Software I - 2006

Requisitos de Software

Custo aumenta com o tempo de descoberta do erro


Custo de reparo Custo de perda de oportunidades Custo de perda de clientes

Engenharia de Software I - 2006

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

Requisitos de Software
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 de Software
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

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Requisitos de Software
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.
Engenharia de Software I - 2006

Onde o sistema funcionar?

Engenharia de Software I - 2006

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

Requisitos de Software
Categorias de Requisitos: 1) Requisitos Funcionais (RF)
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Requisitos de Software
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

Requisitos de Software
Categorias de Requisitos: 1) Requisitos Funcionais (RF) Exemplos:
Engenharia de Software I - 2006

Requisitos de Software
Categorias de Requisitos:
2) Requisitos No-Funcionais (RFN)
Engenharia de Software I - 2006

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

Requisitos de Software
Categorias de Requisitos:
2) Requisitos No-Funcionais (RFN)
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Requisitos de Software
Categorias de Requisitos:
2) Requisitos No-Funcionais (RFN)

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

Requisitos de Software
Categorias de Requisitos:
2) Requisitos No-Funcionais (RFN)
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Requisitos de Software
Categorias de Requisitos:
2) Requisitos No-Funcionais (RFN)

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

Requisitos de Software
Categorias de Requisitos:
2) Requisitos No-Funcionais (RFN)
Exemplos
Engenharia de Software I - 2006

Requisitos de Software
Taxonomia
Requisitos de Processo

Requisitos no funcionais
Requisitos de Produto

Requisitos Externos

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 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

Requisitos de Software
Categorias de Requisitos: 3) Requisitos Inversos (RIN) So requisitos que definem estados e situaes que nunca devem ocorrer.

Requisitos de Software
Requisitos
Clientes
Engenharia de Software I - 2006

RF Usurios

Engenharia de Software I - 2006

Necessidades Limitaes Impossibilidades RNF RIN Infra Estrutura Tecnolgica


26

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

RNF

25

Requisitos de Software
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 de Software
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.

Engenharia de Software I - 2006

Engenharia de Software I - 2006

28

Requisitos de Software
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

Requisitos de Software
Definio e Especificao Exemplo: Defini Especifica Definio de Requisito Defini

Engenharia de Software I - 2006

Engenharia de Software I - 2006

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 de Software
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 de Software
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

Requisitos de Software
Medidas de Requisitos
Propriedade Medidas possveis poss

Requisitos de Software
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

Engenharia de Software I - 2006

Tamanho Usabilidade

Confiabilidade

Robustez Portabilidade

Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

Introduo Engenharia de Requisitos


Anlise e especificao de requisitos pode parecer tarefa simples. Entretanto,
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Engenharia de Software I - 2006

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

Engenharia de Requisitos Introduo


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

Engenharia de Software I - 2006

Engenharia de Requisitos Introduo


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

Engenharia de Software I - 2006

Engenharia de Requisitos Introduo


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

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Engenharia de Requisitos Introduo


Por que Engenharia de Requisitos???
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Engenharia de Requisitos Introduo


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

45

46

Engenharia de Requisitos Introduo


Processo de Produo de Requisitos:

Engenharia de Requisitos Introduo


Processo de Produo de Requisitos: Ian Sommerville, quatro etapas
Engenharia de Software I - 2006

Elicitao Registro

Engenharia de Software I - 2006

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

Engenharia de Requisitos Introduo


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
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Engenharia de Requisitos Introduo


Processo
Anlise Elicitao Modelagem V&V

49

50

Mundo Real

Elicitao
Inspirao: Guilherme Nicodemos -UCP

Elicitao
Solues

Problemas
Engenharia de Software I - 2006

Identificar as fontes de informao Coleta de fatos


Engenharia de Software I - 2006

Gap Semntico

Mundo Computacional

Elicitao de Requisitos

51

52

Identificao de Fontes de Informao


Atores do Universo de Informaes
Engenharia de Software I - 2006 Engenharia de Software I - 2006

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


Engenharia de Software I - 2006 Engenharia de Software I - 2006

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?
Engenharia de Software I - 2006

Engenharia de Software I - 2006

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
Engenharia de Software I - 2006 Engenharia de Software I - 2006

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
Engenharia de Software I - 2006

Entrevistas
+
contato direto com atores possibilidade de validao imediata
Engenharia de Software I - 2006

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
Engenharia de Software I - 2006

Engenharia de Software I - 2006

disperso custo

63

64

Observao
+ baixo custo pouca complexidade da tarefa
Engenharia de Software I - 2006

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:
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Engenharia de Software I - 2006

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?

Engenharia de Software I - 2006

Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

Num. de Respostas

71

Engenharia de Software I - 2006

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
Engenharia de Software I - 2006
Num. de Respostas

Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

Engenharia de Software I - 2006

Utilidade geral

Boehm 76

Aumentabilidade
76

75

Mundo Real

Modelagem
Inspirao: Guilherme Nicodemos -UCP

Mundo Computacional

Modelar
Para que servem modelos?
Representao Representa Organizao Organiza Armazenamento Comunicao Comunica

Solues
Engenharia de Software I - 2006

Problemas Gap Semntico

Modelagem dos Requisitos

77

Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

79

Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

Engenharia de Software I - 2006

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.
Engenharia de Software I - 2006 Engenharia de Software I - 2006

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
Engenharia de Software I - 2006

Engenharia de Software I - 2006

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
Engenharia de Software I - 2006

Engenharia de Software I - 2006

Excesso de Especificao ( decises de desenho) Inconsistncia Ambiguidade Referncia futura Requisitos que no podem ser testados

88

Mundo Computacional

Mundo Real

Anlise
Inspirao: Guilherme Nicodemos -UCP

Anlise
Engenharia de Software I - 2006

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)

Engenharia de Software I - 2006

entre modelos

entre o UdI e um modelo

91

Engenharia de Software I - 2006

Prottipos
Vantagens:
Engenharia de Software I - 2006 Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

98

Gerncia de Requisitos
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

Gerncia de Requisitos
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].

Engenharia de Software I - 2006

99

Engenharia de Software I - 2006

100

Gerncia de Requisitos
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

Gerncia de Requisitos
elicitar requisitos implementar rastreabilidade Requisitos

Engenharia de Software I - 2006

Engenharia de Software I - 2006

modelar requisitos

gerenciar evoluo

validar requisitos
102

Gerncia de Requisitos
abordagem sistemtica para:
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Gerncia de Requisitos
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

Gerncia de Requisitos
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

Gerncia de Requisitos
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

Engenharia de Software I - 2006

Gerncia de Requisitos
necessrio, definir um conjunto polticas. necessrio definir um conjunto objetivos para o processo de gerncia. de de
Engenharia de Software I - 2006

Engenharia de Software I - 2006

Gerncia de Requisitos
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.

Engenharia de Software I - 2006

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

Gerncia de Requisitos
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

Gerncia de Requisitos
Rastreabilidade
Pr-rastreabilidade
Engenharia de Software I - 2006 Necessidade dos cliente e documentos Requisitos

Ps-rastreabilidade
Artefatos de designer e implementao

Engenharia de Software I - 2006

110

Gerncia de Requisitos
Rastreabilidade

Gerncia de Requisitos
Rastreabilidade elos

Pr-Rastreabilidade
Engenharia de Software I - 2006

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

Engenharia de Software I - 2006

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

Gerncia de Requisitos
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

Gerncia de Requisitos
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.

Engenharia de Software I - 2006

Engenharia de Software I - 2006

114

Gerncia de Requisitos
Rastreabilidade na Prtica
Matriz de Rastreabilidade entre requisitos e entidades geradas no processo de desenvolvimento
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Gerncia de Requisitos
Rastreabilidade na Prtica
Matriz de Rastreabilidade entre requisitos funcionais e no funcionais

115

116

Gerncia de Requisitos
Rastreabilidade na Prtica Ferramentas
Engenharia de Software I - 2006 Engenharia de Software I - 2006

Gerncia de Requisitos
Requisite Pro

IBM/Rational Requisitepro Controla

117

118

Gerncia de Requisitos
Requisite Pro

Gerncia de Requisitos
Requisite Pro

Engenharia de Software I - 2006

119

Engenharia de Software I - 2006

120

Requisitos de Software

Engenharia de Software I - 2006

Estrutural (dados)

Comportamental (estados e eventos)

Vises para um problema (aspectos fundamentais do software)

[FOWLER96] Arquitetural (operaes)


121