paulo f. vasconcellos finito@pfvasconcellos.eti.br

Paulo F. Vasconcellosfinito@pfvasconcellos.eti.br

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– finito@pfvasconcellos.eti.br– 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

O Q

UE P

REC

ISA

SER

FEIT

O?

www.pfvasconcellos.eti.brfinito@pfvasconcellos.eti.brSkype:pfvasconcellos