Paulo F. [email protected]
Programação
• Requisitos (Engenharia de)– RUP, OpenUP, BABoK...
• Gerenciando Requisitos (e Mudanças)
• Entendendo os Requisitos
• Desenvolvendo Requisitos
• Analisando, Validando e Priorizando
• Viabilizando o Projeto
Objetivos
• Entender os Requisitos
• a disciplina Engenharia de Requisitos
• e os Métodos e Processos que a formam.
• Quem executa
• O que executa / o que gera
• Como
A Oficina
• 5 Grupos de 10 pessoas.
• 1 Monitor para cada grupo.
• Exercícios (6) terão limite de tempo.
• O problema de negócio é relativamente simples.
• Vamos nos concentrar no processo, nos métodos e técnicas.
• Ênfase: técnicas de coleta, descoberta, análise e especificação de requisitos.
Flashback
Oficina: O Problema
• Grande rede de locadoras de DVD's• Quer expandir base de clientes e,• consequentemente, o faturamento• Sem aumentar o número de lojas
• Imagina um serviço de locação via web
Alguns fatos
• 50 Lojas (Sampa e interior)• 25 mil clientes ativos• R$ 5 é o valor médio da locação• R$ 1,5 milhão é o faturamento mensal• 3 DVD's / cliente / semana• As lojas são caras e franquia não é
alternativa
Objetivos
• 250 mil clientes, em todo o Brasil(existem mais de 10 milhões de DVD players por aí)
• Multiplicar por 10 o faturamento• Em 1 ano• Receita recorrente: Mensalidade• Plano de 12 DVD's/mês = R$ 60
(2 lotes com 6 DVD's)• Não há taxa de permanência• Mas cliente só recebe novo lote após devolução
Estratégia
• Pontos fortes– Acervo: 50+ mil títulos– Qualidade do Atendimento (personalizado)
• Oportunidade: Serviço Web é inédito• Ameaça: 'canibalização' das lojas• Ponto fraco: preço• Proposição de Valor: APRISIONAMENTO
Engenharia de Requisitos
Tipos de Processos
“Cascata”(“7 Quedas” ou “Clássico”)
Iterativo & Incremental
Iterativo e Incremental
RUP (Rational Unified Process)
RUP: Requisitos
OpenUP (antes, OpenUP/Basic)
RUP / OpenUP
Equipe de Projeto
RUP, OpenUP e o AN
BABoK: Disciplinas
Engenharia de Requisitos: A Disciplina
Engenharia de Requisitos: A Disciplina
Gerenciando Requisitos
Gerenciamento de Mudanças
Gerenciamento de Mudanças
Antecipando Mudanças eGerenciando Riscos
• Estratégia mal definida, difundida ou executada;
• Processos Doentes;
• Usuários: dúvidas ou decisões “fracas”;
• Requisitos não satisfazem plenamente o checklist.
Controlando Requisitos
Iterativo e Incremental
Entendendo os Requisitos
Definindo Requisitos
• Uma funcionalidade específica;
• Uma propriedade geral do sistema;
• Uma restrição específica do sistema;
ou
• Uma restrição ao desenvolvimento
do sistema.
Tipos de Requisitos
• Requisitos de Negócio
• Requisitos de Usuário
• Requisitos Funcionais
• Requisitos Não-funcionais
Estruturando Requisitos
Estruturando Requisitos
Estruturando Requisitos II
Ponto de Vista
• Estratégico• Tático• Operacional• Técnico
Grau de Importância
• Fundamental• Importante• Opcional
Relações entre Requisitos
• Dependente• Complementar• Substituto• Conflitante
Status
• Pendente• Aprovado• Recusado• Substituído• Implementado• Verificado• Excluído
Estruturando Requisitos
Estruturando Requisitos– De 25 mil para 250 mil
clientes, em todo o Brasil
– Multiplicar por 10 o faturamento
– Em 1 ano
– Receita recorrente: Mensalidade
Desenvolvendo Requisitos
UML: 5 Visões
Casos de Uso – 4 Dimensões
• Propósito: Requisitos ou histórias?
• Conteúdo: “Papo” consistente, Contraditório ou Formal?
• Pluralidade: Um ou Vários Cenários?
• Estrutura: Não estruturado, Semi-formal ou Formal?
Casos de Uso – Motivações:
• Descobrir e descrever os requisitos funcionais de um sistema;
• Fornecer uma clara e consistente visão do que o sistema deve realizar;
• Servir como a base que irá nortear todos os testes do sistema;
• Permitir o rastreamento total entre requisitos e artefatos construídos.
Diagramas de Casos de Uso
Diagramas de Casos de Uso
Especificações de Casos de Uso• [Número] e Nome do Caso de Uso:• Processo de Negócio:• [Resumo:]• Objetivos:
– 1 ...– 2 ...
• Ator Principal:• Fato Gerador (Evento de Negócio):• Fluxo Principal:
– 1 ...– 2 ...
• 2.1 ...• 2.2 ...
– 3 ...• Regras de Negócio:• [Pré e pós-condições:]• [Extensões / Fluxos Alternativos:]• [Requisitos complementares:]
Estruturando Requisitos III
Por onde começar?
Por onde começar?
Técnica: Entrevistas
• BABoK: – Maneira sistemática de levantar
informações de uma pessoa ou grupo– De maneira formal ou informal– Perguntando questões relevantes e
documentando as respostas.• Pró: Objetividade• Contra: Falta de pontos de vista
divergentes• Indicações:
– 1 ~6 pessoas– Pauta e duração pré-determinados
Start me Up!
• “Coleta” de RequisitosA Forma Tradicional: Entrevista
• Tempo Limite: 30 Minutos
• Monitor = Dono do Negócioou seja, [Ponto de Vista = Estratégico]
• Grupo:– Todos revezam na função do AN que
conduz a entrevista
– Todos devem registrar os “achados”
• Foco: Visão Geral do PROBLEMA
Entrevistas: Atenção!
• Entrevistado titubeou?Cada “derrapada” é um risco para o projeto.
• Se 1ª Entrevista:2km de extensão – 2cm de profundidade.
• Temos todos os requisitos do usuário?
Perguntando de outra forma:
• Temos todos os Casos de Uso?
• Vamos validar?
Pior Cenário
Aprendendo
Quente X Frio [EUP – Avaliando Canais]
Quente x Frio [Avaliando Técnicas]
Quente x Frio [Avaliando Técnicas]
Socialização
• Entrevistas
• Workshop / Brainstormings(aka “Face-to-face at whiteboard”)(aka “Toró de Parpite”)
Quente x Frio [Avaliando Técnicas]
Técnica: Brainstorming
• BABoK:– Uma excelente forma para levantar idéias
em torno de uma área específica.– O “brainstorming estruturado” produz uma
série de idéias sobre qualquer “questão central”.
• Pró: liberdade de criação.• Contra: perda do foco.• Indicações:
– Usuário “titubeante”; – Fases iniciais de um projeto;– Projeto realmente exige altas doses de
criatividade.• Cuidado: Criatividade depende da
platéia!
Digging in the Dirt
Digging in the Dirt
• Técnica: BRAINSTORMING• Tempo limite: 30 minutos• 4 regrinhas:
– Produza o maior número de idéias;
– De maneira “selvagem”;
– Trabalhe as idéias dos “outros”; e
– Não julgue!
Técnica: Brainstorming
• BABoK:– Uma excelente forma para levantar idéias
em torno de uma área específica.– O “brainstorming estruturado” produz uma
série de idéias sobre qualquer “questão central”.
• Pró: liberdade de criação.• Contra: perda do foco.• Indicações:
– Usuário “titubeante”; – Fases iniciais de um projeto;– Projeto realmente exige altas doses de
criatividade.• Cuidado: Criatividade depende da
platéia!
O Passo Esquecido
Quem acerta na primeira?
“As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção” - Frank Lloyd Wright
“A mais importante ferramenta do físico é sua cesta de lixo.” - Albert Einstein
“As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção”
- Frank Lloyd Wright
“A mais importante ferramenta do físico é sua cesta de lixo.” - Albert Einstein
O Espaço do Problema[Scott Berkun]
Melhor Cenário
Quente x Frio [Avaliando Técnicas]
Técnica: Workshop(ou JAD – Joint Application Development)
• BABoK:– Forma estruturada de captura de requisitos.– Utilizada para descobrir, definir e priorizar
requisitos.– Indicada para “fechar” o escopo do projeto.– Quando bem executado, é uma das
melhores técnicas para o desenvolvimento ágil de requisitos de alta qualidade.
• Pró: agilidade na tomada de decisões.• Contra: perda do foco.• Indicações:
– Número de usuários entre 6 e 20.• Cuidado: Pauta e duração pré-fixados.
I Still Haven't Found what I'm Looking for• Técnica: WORKSHOP• Tempo limite: 30 minutos• Objetivos:
– Agrupar Idéias– Desenvolver Requisitos Funcionais
Caso: Alugar DVD• Atenção: Atributos dos Requisitos
Onde Estamos?
Revendo o Principal Artefato
Caso de Uso #1: Alugar DVD
• Processo: Locação• Fonte(s) / Ponto(s) de Vista:• Ator principal: Cliente• Objetivos:
– a) Montar “lote” de DVD's(selecionar títulos)
– b) Programar entrega dos “lotes”• Importância: FUNDAMENTAL• Pré-condição: Cliente deve estar cadastrado.
Caso de Uso #1: Alugar DVD
• Fluxo (cenário) Principal:– 1. Cliente se identifica– 2. Seleciona seção– 3. Escolhe os títulos– 4. Organiza lotes para entrega– 5. Confirma operação
Caso de Uso #1: Alugar DVD
• Fluxos (cenários) alternativos(extensões):– 2a. Cliente pede sugestões– 2b. Cliente recupera lista prévia
• Observações:– 2a é IMPORTANTE– 2b é FUNDAMENTAL
Caso de Uso #1: Alugar DVD
• Regras de Negócio:– Número de títulos por lote é limitado pelo plano contratado.
– Se cliente estiver com 2 mensalidades em atraso, ele deve ser informado que entrega do lote é condicionada ao pagto do débito.
Caso de Uso #1: Alugar DVD
• Requisitos Complementares:– c1. Interface deve ser personalizada para o cliente[FUNDAMENTAL]
– c2. Sempre apresentar lista de sugestões e lançamentos.[IMPORTANTE]
– c3. Oferecer busca de títulos por nome, diretor/ator e tipo.[FUNDAMENTAL]
– c4. Tela deve ser simples e rápida. (1 clique por título).[FUNDAMENTAL]
Revendo o Principal Artefato
Revendo o principal Artefato
Técnica: Prototipação
• BABoK:– Quando utilizada como técnica para coleta de
requisitos, visa a elaboração dos requisitos de interface.
• Pró: Redução do “vapor” que é o software.• Contra: Alto risco de “criatividade” demais.• Indicações:
– Toda interface crítica do projeto;– Clientes muito inseguros.
• Atenção: Requisitos devem ser formalizados!
• Observação: pode ser utilizada como técnica auxiliar em workshops e brainstormings.
Prototipação (Storyboards)
Prototipação (Storyboards)
Finish what ya Started
• Técnica: Prototipação• Tempo Limite: 30 minutos• Objetivos:
– Detalhar requisitos funcionais– Validar requisitos
• No grupo:– Monitor = Dono do negócio– 1 designer– 1 AN conduzindo o trabalho– Demais integrantes devem detalhar,
validar e registrar os requisitos
Outras Técnicas: Internalização
• Observação– Ativo– Passivo
• Engenharia Reversa– Caixa Preta– Caixa Branca
• Pesquisa– Questionários– Versões de Testes
(aka “The Google Way”)
Quente x Frio [Avaliando Técnicas]
Meet in the Middle
Qualidades dos Bons Requisitos• Completo• Correto• Viável• Necessário• Priorizado• Não Ambíguo• Verificável
Características dos Bons Casos de Uso (e das User Stories)
• Independentes• Negociáveis• Valiosos para Usuários e Clientes• Estimáveis• Pequenos• Testáveis
Definindo Prioridades
• Fundamental• Importante• Opcional
• Custo de implementação• Prazo para
implementação• Facilidade da
implementação técnica• Facilidade da
implementação no negócio
• Atendimento de algum requerimento legal, regulatório ou contratual
Definindo Prioridades
PrioridadeDificuldade Técnica
Grau de Importância
Caso de Uso
Ator
•Simples•Médio•Complexo•Muito Complexo•Um pesadelo!
Definindo Prioridades
Dificuldade Técnica
• Avaliação da Equipe
• Pontos por Caso de Uso
Pontos por Caso de Uso(Contagem de Atores)
3Pessoas invocando o caso de uso através de uma interface gráfica.
Complexo
2Pessoas utilizando uma interface texto ou um outro sistema se comunicando através de algum protocolo.
Médio
1Outro sistema se comunicando através de uma API (Application Programming Interface).
Simples
PontosDescriçãoAvaliação
Pontos por Caso de Uso(Contagem de Casos de Uso)
15Mais de 8 cenários.Complexo
10Entre 4 e 8 cenários.Médio
5Menos de 4 cenários ou caminhos de execução.
Simples
PontosDescriçãoAvaliação
Pontos por Caso de UsoContagem por Pontos de Caso de Uso (UUCP) não ajustados
(# Atores X Pontos) +
(# Casos X Pontos)------------------------------
U U C P
Pontos por Caso de UsoFator de Ajuste
• 20% - Tecnologia OU Equipe “nova”• 40% - Tecnologia E Equipe “novas”• 100% - Tecnologia E Equipes “novas”
E o Cliente é um “mala”
Pontos por Caso de UsoCalculando o Esforço
• X (total de pontos obtido no cálculo anterior)
• Multiplicamos X por 20 horas!
• ou 24• ou 36• ou 48• ou 16...
Murder by Numbers
• Analisar e Priorizar Requisitos• Tempo Limite: 20 minutos• Objetivos:
– Analisar Requisitos– Estimar e Priorizar Requisitos– Fechar 1ª versão do escopo
Cabe tudo num Caso de Uso?
Casos de Uso e Documentos Complementares
O “Grande” Documento[Cockburn / Robertson]
• Capítulo 1: Objetivos e Escopo– Objetivos do Projeto– Stakeholders – Escopo / fora do escopo
• Capítulo 2: Glossário• Capítulo 3: Os Casos de Uso
– Atores e respectivos objetivos– Casos de Uso de Negócio– Casos de Uso de Sistema
O “Grande” Documento[Cockburn / Robertson]
• Capítulo 4: Tecnologia– A Tecnologia que será utilizada– Integração com outros sistemas
• Capítulo 5: Outros Requisitos– Processo de Desenvolvimento– Regras de Negócio– Performance– Operações, Segurança e Documentação– Uso e Usabilidade– Manutenção e Portabilidade– Não resolvidos ou negados
• Capítulo 6: Questões Legais, Políticas e Organizacionais
Viabilizando o Projeto
Definindo o Escopo
O Documento de Visão[Berkun: “Insanamente Simples”]
O Documento de Visão[Berkun: “Insanamente Simples”]
O Documento de Visão[Berkun: “Insanamente Simples”]
O Documento de VisãoBerkun: “Insanamente Simples”
O Documento de VisãoCaracterísticas Básicas
• Simples• Guiado pelos Objetivos• Consolidado• Inspirador• Memorável
Estrutura Básica
• Problemas / Oportunidades– Descrição resumida
• Destacar processos de negócio– Apresentação dos stakeholders
• Solução(ões)– Breve descrição
• Relacionar com problemas– Estimativas Iniciais– Suposições e Dependências– Idéias para Versões Futuras
Zabriskie Point
• Desenvolver o Documento de Visão• Tempo limite: 15 minutos!• Dá um tempo! Uma página só!
• Agora é competição:– Simples– Guiado pelos Objetivos– Consolidado– Inspirador– Memorável
ops... it's what the business needs!
O Livro: “É o Negócio, Beócio”
• Garantia de AtualizaçãoVersão Eletrônica (até versão 1.0)
• Previsão de Lançamento: Março/2008
• Sua participação é fundamental!– http://groups.google.com/group/an-br– [email protected]– http://www.pfvasconcellos.eti.br
Bibliografia Recomendada• Software Requirements
Karl Wiegers – MS Press (1999)• More About Software Requirements
Karl Wiegers – MS Press (2006)• Requirements-Led Project Management
Suzanne e James Robertson – Addison-Wesley (2005)• Writing Effective Use Cases
Alistair Cockburn – Addison-Wesley (2000)• Requirements Engineering
Ian Sommerville e Pete Sawyer – Wiley (1997)• Agility and Discipline Made Easy: Practices
from OpenUP and RUPPer Kroll e Bruce MacIsaac – Addison-Wesley (2006)
• The Art of Project ManagementScott Berkun – O’Reilly (2005)
Na Web
• IIBA – International Institute of Business Analysiswww.theiiba.org
• BPM Forumhttp://br.groups.yahoo.com/group/BPM-Forum/
• UML-BRhttp://br.groups.yahoo.com/group/UML-BR/
• Business Analysis Insighthttp://www.bainsight.com
Créditos & Débitos
• Tks! – Tempos Real Eventos– BPM Forum / UML-BR / CMM-BR
• Apresentação liberada sob licençaCreative Commons (by+sa) 2.5 Brasil
Top Related