Gerncia de Requisitos

Karin Koogan Breitman

Karin@inf.puc-rio.br www.inf.puc-rio.br/~karin

Custo de correo

Custo de correo

Custo aumenta com o tempo de descoberta do erro

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

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.

Requisitos-1 (Requisitos Inversos)

RIN estabelecem condies que nunca podem ocorrer.
5

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.

{Julio Cesar Leite}

7

Porque Gerenciar Requisitos?

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

Elicitao Modelagem Anlise Validao Verificao

10

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

11

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

Identificar as fontes de informao Coleta de fatos

14

Identificao de Fontes de Informao

Fonte Julio Cesar Leite

Atores do Universo de Informaes

Clientes Usurios Desenvolvedores

Documentos Livros Sistemas de Software

15

Heursticas para identificao de fontes de informao

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

Trivial Internalizado Nunca lembrado!

Problema de comunicao No de requisitos!!!!

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

20 Ian Alexander, Writing better requirements

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

Os usurios misturam a soluo com os requisitos

Separar NECESSIDADE da soluo proposta ou atual!

22

Entrevistas
Fonte Julio Cesar Leite

+
contato direto com atores possibilidade de validao imediata

conhecimento tcito diferenas culturais

23

Reunies
Fonte Julio Cesar Leite

Extenso da entrevista Brainstorm JAD Workshop de Requisitos

24

Reunies
Fonte Julio Cesar Leite

+
dispor de mltiplas opinies criao coletiva

disperso custo

25

Observao
Fonte Julio Cesar Leite

+ baixo custo pouca complexidade da tarefa

dependncia do ator (observador) superficialidade decorrente da pouca exposio ao universo de informaes

26

Enfoque antropolgico
Fonte Julio Cesar Leite

+
viso de dentro para fora contextualizada

tempo pouca sistematizao

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

Qualitativo Quantitativo O que perguntar

exige conhecimento mnimo similar a entrevista estruturada

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)

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

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

Num. de Respostas

33

Questionrios
Fonte Julio Cesar Leite

+
padronizao de perguntas tratamento estatstico

limitao das respostas pouca interao/participao

34

Bases de Requisitos nofuncionais

Taxonomias propostas na literatura Servem de guia para a elicitao

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

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 processar depsitos rapidamente

O sistema CE deve escanear os dados do usurio e conta de cada folheto de depsito em 2 segundos ou menos

Ralph Young effective requirements practices

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)

Amigvel Portvel Pequeno Flexvel

Variveis que podem acomodar uma gama de mudanas de valores Funes que implementam uma de vrias possibilidades 39

Ralph Young effective requirements practices

Base de RNFs
Fonte Julio Cesar Leite

+
reutilizao de conhecimento antecipao de aspectos implementacionais identificao de conflitos

custo de construo de base RNF falsa impresso de completeza

40

Engenharia Reversa
Fonte Julio Cesar Leite

+ disponibilidade de informao (cdigo) reuso descontinuidade de informaes informao muito detalhada

41

Reutilizao
Fonte Julio Cesar Leite

+
produtividade qualidade

nvel de abstrao (requisitos) possibilidade de reuso real

42

Modelagem

Mundo Computacional

Modelagem
Mundo Real
Inspirao: Guilherme Nicodemos -UCP

Solues
Problemas Gap Semntico

Modelagem dos Requisitos 44

Modelar

Para que servem modelos?

Representao Organizao Armazenamento Comunicao

45

Abstrao
Fonte: S. Easterbrook - UofT

Ferramenta mais utilizada na racionalizao de software Porque?

Ignorar detalhes incovenientes Possibilita o mesmo tratamento a entidades diferentes Simplifica vrios tipos de anlise

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

Tcnicas de Modelagem Orientadas Especificao

Fonte Julio Cesar Leite

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

Exerccio - Caso de Uso

Pedir promoo no McDonalds
1.

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

Um caso de uso realiza um aspecto maior da funcionalidade do produto:

deve gerar um ou mais benefcios para o cliente ou para os usurios Podem representar:
roteiros de interao com usurio roteiros do manual de usurio casos de teste

Filho, W.P.P em Engenharia de Software: Fundamentos, Mtodos e Padres

51

Diagrama de Caso de Uso Sintaxe

Ator (Actor)

Caso de Uso (Use Case) Interao

52

Diagrama de Casos de Uso Exemplo

Caixeiro Operao de Venda
Sistema Financeiro Gestor de Estoque Gesto Manual de Estoque

Abertura do Caixa

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

[Unified Software Development Process Jacobson, Booch, Rumbaugh]

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

Ex: modificar endereo da cobrana

Estratgia de Caso de Uso:

Refrazear para O que voc quer que o sistema faa PARA CADA USURIO?
55

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

Casos de Uso [Cockburn]

Comprar aes na Web

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

Caso de Uso [Constantine e Lockwood]

Cliente
Entra nmero da ordem de servio (OS)
Detecta que o nmero da OS casa com o nmero do vencedor do ms

Sistema

Registra o nmero da OS como vencedora do ms

Manda mensagem de e-mail para o representante de vendas Congratula o cliente e fornece instrues para a coleta do prmio Sai do sistema
58

Casos de Uso [W.P.P. Filho]

<< Operao de Venda>>

pre-condies: Toda mercadoria a ser vendida (item de venda)

deve estar previamente cadastrada. O Merci deve estar em Modo de Vendas.

fluxo principal
O Caixeiro faz a abertura da venda.

O Merci gera o cdigo da operao de venda.

Para cada item de venda aciona o subfluxo Registro. O Caixeiro registra a forma de pagamento. O Caixeiro encerra a venda. Para cada item aciona o subfluxo Impresso de Linha do Ticket.

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

Filho, W.P.P em Engenharia de Software: Fundamentos, Mtodos e Padres

59

Casos de Uso (RUP)

1.

Nome
Descrio Atores Disparadores

2.

Fluxo de eventos
Fluxo bsico Fluxo alternativo

Condio 1 Condio 2

3.

Requisitos Especiais
Plataforma

4. 5. 6.

Pr condies Ps Condies Pontos de Extenso

60

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

Atributos de uma boa especificao

Clareza ! Ambgua Completa Simples Bem escrita

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

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

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
69

Anlise

Mundo Computacional

Anlise
Mundo Real
Inspirao: Guilherme Nicodemos -UCP

Problemas

Solues Gap Semntico

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

entre o UdI e um modelo

72

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

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

Organizador Moderador Inspetor

Processo

Autor
Secretrio Relator

Papis

Inspeo
Tcnicas de leitura

Artefatos

a serem inspecionados para conduzir a inspeo

Ad hoc Check lists Abstrao de erros

baseada em Pontos de Funo Baseada em Perspectivas

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

Escopo Mudanas CMM Priorizao Rastreabilidade

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?

Combinao de funcionalidade, recursos e tempo:

RECURSOS

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

Requisitos & Certificao

Fonte SEI Mark Paulk

Otimizao (5)
Foco na melhoria de processo

A melhoria de processo est institucionalizada

Gerenciado (4)
Processo medido e controlado

Produto e processo so qualitativamente controlados

Definido (3)
Processo caracterizado, completamente bem entendido

A engenharia de software e os processos de gerenciamento so definidos e integrados

Repetvel (2)
Pode repetir tarefas previamente dominadas

O sistema de gerenciamento de projeto adequado; o desempenho fcil de repetir

Inicial (1)
Imprevisvel e pouco controlado

O processo informal 88

Estrutura do CMM
Fonte SEI Mark Paulk

Nveis de maturidade Indicam Capacidade do processo

Contm
Key process areas So organizadas por

Atingem
Common features Contm

Metas Levam a

Implementao ou institucionalizao

Key practices Descrevem

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

Meta Gerncia de Requisitos

Fonte Claudia Hazan

Atividades I revisar os requisitos de software, antes de incorpor-los ao projeto

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

Meta Gerncia de Requisitos

Fonte Claudia Hazan

Atividades II

Utilizar os requisitos alocados como base para as atividades do desenvolvimento de software.

Gerenciados e controlados Base para o desenvolvimento dos requisitos de Sw Base para o plano de desenvolvimento de Sw Base para o Projeto do Sw.

92

Meta Gerncia de Requisitos

Fonte Claudia Hazan

Atividades III

Revisar alteraes nos requisitos alocados e incorporlas ao projeto de software

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.

O impacto nos compromissos existentes avaliado e mudanas so negociadas, quando apropriado.

93

Mudanas

ERRO: congelar requisitos aumento na compreenso dos requisitos

maior clareza melhor definio

erros fatores externos ao sistema

mudanas no UdI

inesperado
94

Mudanas
Fonte Julio Cesar Leite

Real

Desejado

Mudanas Requisitos incompletos Requisitos inconsistentes

Requisitos fixos Requisitos completos Requisitos consistentes Fregueses em unssono

95

Alteraes nos requisitos

As alteraes que precisam ser feitas nos planos de software, artefatos e atividades resultantes da alterao dos requisitos so:

- Identificadas - Avaliadas - Avaliadas sob o ponto de vista de risco - Documentadas - Planejadas Comunicadas aos grupos e indivduos envolvidos - Acompanhadas at a finalizao
96

Formulrio de solicitao de alterao

Formulrio de Solicitao de Mudana
Solicitante: Tipo: (excluso, alterao, novo requisito) Justificativa: Anlise de Impacto : Fase de ocorrncia:

97

Como tratar alteraes

Verses de requisitos Gerncia de configurao Baseline de requisitos

98

http://stones.les.inf.puc-rio.br/karin/exemplo/index.html

Evoluo
Fonte Julio Cesar Leite

99

O que priorizar? [Wiegers]

Trade off entre:

escopo tempo recursos

Garantir que o essencial realizado

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

Tcnicas informais [Leffingwell]

R$100
durante uma reunio cada participante recebe R$100 para gasto na compra de requisitos escrever em um papel quanto do dinheiro gastaria em cada requisito tabular resultados ranking dos requisitos
103

Outras escalas de priorizao de requisitos: [Wiegers]

IEEE 1998
essencial
software no aceitvel a no ser que estes requisitos sejam implementados

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

Identificar requisitos com componentes de software

Fonte Julio Cesar Leite

tambm chamado rastreamento, porque deve permitir a navegabilidade dos produtos de software, a incluindo os requisitos, em relao as solicitaes dos clientes.

105

Rastreabilidade o que ???

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