Engenharia De Requisitos Software Orientado Ao Negocio

Prévia do material em texto

Engenharia de Requisitos.
Software Orientado ao negócio
Carlos Eduardo Vazquez
Guilherme Siqueira Simões
Rio de Janairo: Brasport, 2016
ISBN: 978-85-7452-790-1
Direitos autorais e conteúdo
• Estudo retirado do livro:
ENGENHARIA DE REQUISITOS : Software Orientado ao Negócio
Carlos Eduardo Vazquez
Guilherme Siqueira Simões
Rio de Janeiro: Brasport, 2016
ISBN: 978-85-7452-790-1
Base: .
IEEE830
ISO 9000
ISO/IEC 12207
ISO 9126
SOMMERVILLE, Ian . Engenharia de Software, 9ª Edição. Pearson Education, 2011.
PRESSMAN, R. S. Engenharia de Software. 7º Edição. Editora McGraw Hill. Rio de Janeiro, 2010.
Conteúdo
– 1. Engenharia de Requisitos
– 2. Requisitos
– 3. A Importância da Engenharia de Requisitos
– 4. Dificuldades Comuns com Requisitos
– 5. Tipos de Requisitos, Restrições e Premissas
– 6. Atividades de Engenharia de Requisitos
– 7. Elicitação de Requisitos
– 8. Análise de Requisitos
– 9. Gerência de Requisitos
Início da Jornada
Necessidade de nossos clientes.. Entenda !!
1. Engenharia de Requisitos
• Primeiro passo:
• Entender o que significa !
• “- Quando eu uso uma palavra - disse Humpty Dumpty num tom
escarninho - ela significa exatamente aquilo que eu quero que signifique ...
nem mais nem menos. - A questão - ponderou Alice saber se o senhor pode
fazer as palavras dizerem coisas diferentes. - A questão - replicou Humpty
Dumpty é saber quem é que manda. É só isso. (Alice no País das
Maravilhas)”
Lewis Carroll
Terça
1.1. Definição de Engenharia de Requisitos
• Isto é:
• Consiste no uso sistemático e repetitivo de técnicas para
cobrir atividades de obtenção, documentação e manutenção
de um conjunto de requisitos de software que atendam aos
objetivos de negócio e sejam de qualidade
Terça
1.2. Por que usar “engenharia” em Engenharia 
de Requisitos?
• Pois está ligada à aquisição e aplicação de conhecimento para 
criação, aperfeiçoamento e implementação de sistemas de 
informações.
Melhore
Pergunte
Imagine
Planeje
Crie
Terça
Estratégias de desenvolvimento
Terça
Estratégias de desenvolvimento
Terça
Estratégias de desenvolvimento
Terça
Estratégias de desenvolvimento
Terça
Estratégias de desenvolvimento
Terça
Ambiente da Engenharia de Requisitos
• Facilita a interação com o cliente.
– Identificar e entender suas necessidades
– Acordo da solução a ser entregue
• Inicia com o entendimento da necessidade do cliente e;
• Passa pelo acordo sobre a solução que será construída
Terça
Contexto
Terça
Requisito
Terça
Tipos de requisitos
• IEEE830/98
• Requisitos Funcionais
• Requisitos Não Funcionais
• Requisitos de Domínio
Terça
Requisitos Funcionais
• Descrevem explicitamente as funcionalidades e serviços do sistema
• Documenta
– como o sistema deve reagir a entradas específicas
– como deve se comportar em determinadas situações
– o que o sistema não deve fazer
• Atributos
– Completude
• Todas os serviços devem estar definidos
– Consistência
• Os requisitos não devem ter definições contraditórias
• Na prática, é quase impossível atingir completude e 
consistência dos requisitos
Terça
Requisitos Não Funcionais
• Definem propriedades e restrições do sistema
– Exemplos: segurança, desempenho, espaço em disco
• Podem ser do sistema todo ou de partes do sistema
• Requisitos não funcionais podem ser mais críticos que
requisitos funcionais
– Se não satisfaz, o sistema é inútil
Terça
Entender seu significado
• Não confundir:
– Requisitos = documentação
– Requisitos = Software (Completo)
• Está direcionado á
– Necessidade
– Propriedade
– Especificação
Terça
Definição de requisito
• ISSO/IEC/IEEE
• Uma condição ou capacidade do sistema, solicitada por um usuário,
para resolver um problema ou atingir um objetivo;
• Uma condição ou capacidade que deve ser atendida por uma
solução para satisfazer um contrato, especificação, padrão ou
quaisquer outros documentos formais;
• Documentação de representação das condições ou capacidade nos
dois itens anteriores;
• Uma condição ou capacidade que deve ser alcançada ou possuída
por um sistema, produto, serviço, resultado ou componente para
satisfazer um contrato, padrão, especificação ou outro documento
formalmente imposto. Requisitos incluem as necessidades
quantificadas e documentadas, desejos e expectativas do
patrocinador, cliente e outras partes interessadas.
Terça
Especificação de requisitos
• É um contrato entre cliente e equipe de desenvolvimento.
– Então ambos obrigatoriamente serão seus leitores
• Deve estabelecer aos clientes o que será entregue como 
produto do trabalho da equipe de desenvolvimento.
• Serve de base para manutenções futuras.
Terça
Nível de detalhe
• A falha em não detalhar de maneira suficiente as informações
na especificação de requisitos pode levar a interpretações
equivocadas ou à criação de um número elevado de
premissas.
• Por outro lado, decidir por detalhar demais as especificações
pode ser um elemento paralisante do projeto (a especificação
nunca é finalizada), além de oneroso.
• O desafio é encontrar o equilíbrio do nível de detalhe
adequado da especificação de requisitos par ao projeto.
• Atenção ::: Deve Delimitar o Escopo..
Terça
Nível de detalhe da especificação
• Definir com clareza o contexto em que ela será usada;
• Decidir dobre quais tipos de informação devem estar
presentes;
• Avaliar os riscos conforme os fatores que podem implicar em
mais ou menos detalhes.
• Grau de incerteza:
– Toda estimativa envolve incerteza (por definição)
• Envolvimento dos clientes
– Fator crítico para o sucesso
Terça
Critérios de qualidade da especificação.
• Correta
• Completa
• Clara
• Consistente
• Modificável
• Priorizada
• Verificável (ou testável) 
• Rasteável
Terça
Importância da engenharia de requisito
• Motivação
• Impactos negativos da falha de requisitos
– Sonda Mars .. Etc..
Terça
Aquecendo os motores
“As pessoas não sabem o que querem,
até mostrarmos a ela”
Steve Jobs
Dificuldades comuns com Requisitos
• Comunicação
Minha esposa disse:
- Amor, vá ao mercado e compre uma caixa de leite. Se eles tiverem ovos, traga seis.
Eu voltei com seis garrafas de leite.
Ela disse:
- Porque você comprou seis garrafas de leite ?
Respondi:
- Porque eles tinham ovos !!
Quarta
Outa dificuldade
• De manter sintonizados todos os envolvidos nos requisitos,
sejam membros da equipe ou partes interessadas.
• O número de canais de comunicação em potencial entre essas
pessoas é 𝑝 =
𝑛 (𝑛−1)
2
Quarta
Acesso às partes interessadas
• Muitas vezes o trabalho de requisitos acontece sem que seja
permitido ao analista interagir diretamente com algumas
partes interessadas.
– Seja por falta de disponibilidade;
– Seja por falta de tempo;
– Seja por falta de interesse da parte interessada;
– Seja por questões políticas, sociais culturais ou outros.
• Princípio 4 dom manifesto Ágil:
– “Pessoas de negócio e desenvolvimento devem trabalhar
diariamente em conjunto por todo o projeto”
Quarta
Indecisões / Indefinições do usuário
• Dificuldade de o usuário saber o que quer.
• Falta de conhecimento da atividade que exerce.
• A princípio podemos pensar que a culpa é do usuário, pois ele
não sabe pedir e nem sabe no que trabalho.
– Se fosse verdade o analista de requisito seria um tomador
de notas.
• Deve procurar métodos mais adequados para obtenção de
informações (Cap. 7 e 8)
Quarta
Muita Dificuldade
• Requisitos Implícitos ou não ditos
– Caso comum: Fizemos um bom trabalho, ouvi as partes
interessadas,li os documentos e confirmou todas as
necessidades.
• Pronto: Na validação/Homologação encontra diversas
necessidades não atendidas pelo produto..... Pois estas
necessidades nunca tinhas faladas ao analista....
• “Claro que não falei sobre isso, pois para mim estava
implícito que isso estaria contemplado. É óbvio que o
produto deveria ter isso !”
– Quem errou neste caso ?
Quarta
Mais difuculdades
• Mudanças.
– Alta frequência de mudança em requisitos.
• Toda mudança acarreta em algum ônus.
– Gestor com outras prioridades.
– Quanto maior o projeto, maior tende sua duração e
consequentemente, maior a incidência de mudanças.
– Gerir mudanças é fundamental
– Resistencia a mudança
Quarta
Parte interessada
• Não domina seu negócio
– Parece algo comum.
• Não lê a especificação de requisitos.
– Ela tem que está de acordo com o que foi solicitado, a
responsabilidade não é só sua.
• Insaciável com requisitos..
– Porque os requisitos se expandem? Porque as partes
interessadas sempre têm necessidade a serem satisfeitas.
Quarta
Um bom trabalho
• Consistência.
– Um bom trabalho de requisitos tem que resultar em uma
especificação de requisitos que seja uma história bem
contada, com início, meio e fim tudo se encaixando.
• Necessidades vagas.
– Encontrar um cenário onde a necessidade apresentada é
mais ou menos vaga.
• Objetivo é transformar estas necessidades vagas em
necessidades claras.
• Priorização.
Quarta
Tipos de requisitos, Restrições e Premissas
• Domínio do problema
Quarta
Domínio
• Qual é a sua importância ?
– Delimita escopo
• Requisitos (ou necessidades) de negócio.
– Declarações de mais alto nível de objetivos, metas ou 
necessidades das organizações.
– Necessidades de negócio são problemas a resolver.
• Critérios de qualidade
– “é tão fácil sugerir uma solução quando você não sabe 
demais sobre o problema.” Malcolm Forbes
Quarta
Método SMART
• Tem como objetivo avaliar a validade de objetivos que devem ser:
• S – eSpecífico : Descreve algo que apresenta um resultado
observável.
• M – Mensurável : São resultados passíveis de acompanhamento e
medição.
• A – Alcançável : As necessidades de negócio consideram a
viabilidade de investimento.
• R – Relevante : Elas estão alinhadas com a visão, a missão e os
objetivos-chave da organização.
• T – Tempestivo : Os objetivos definidos têm uma janela de tempo
definida que é consistente com as oportunidades ou os problemas
associados.
Quarta
Papel do Analista de Requisitos
• É refinar os requisitos de negócio, identificando questões que 
– uma vez respondidas – permitam melhor compreensão das 
intenções iniciais.
• Perguntas podem ser elaboradas para entender o domínio do 
problema.
– Quais são as principais dificuldades na fiscalização e que 
dificultam a coleta de dados ?
– Qual é a sua ideia de agilidade de coleta de dados 
posposta?
– Agilizar em quantos % o processo de coleta de 
informação?
– Como se mede a coleta de informação ?
Quarta
Onde ficam registrados?
• Os registros de negócio costumam estar presentes em
documentos que justifiquem o projeto.
– Caso de negócio (busines case);
– Estudo de viabilidade;
– Anteprojetos;
– Termos de abertura de projeto.
Quarta
Restrições e premissas
• Restrições
– Limitações as possíveis soluções
• Premissas
– Suposições – Informações que se acreditam como 
verdadeiras, mas ainda não foram confirmadas
Quarta
O caminho a partir dos requisitos de negócio
Quarta
Autoridade e responsabilidade
• Usuário que detém o negócio;
• Pessoas que usam o processo.
• Importante e identificar as partes interessadas.
• A responsabilidade do requisito não deve ser imputada 
somente no analista, e sim compartilhada nas partes 
interessadas.
– Habituar a fazer o acordo de aceito com o cliente.
Quarta
Requisitos
• Requisitos de Software, são compostos pelos requisitos da
solução – produto a ser entregue – e pelos requisitos da
transição (se houver) = ambos são compostos pelos requisitos
funcionais
Quarta
Nível de granularidade
• Mais detalhado o possível ou informações macros ?
Quarta
Figura 5.9. Diferentes níveis de 
granularidade em requisitos 
presentes em uma especificação 
funcional e sua relação com os 
objetivos associados
Atenção
• Diferença entre requisitos não funcionas e restrições técnicas.
• RNF = É o resultado de uma elaboração “de escolha” para uma 
solução em particular dentre muitas possíveis.
• RT = São limitações impostas externamente as possíveis 
soluções.
Quarta
Quase no fim.....
Atividades da Engenharia de Requisitos
“A luz precede toda transição, Seja a luz no fim do túnel,
Pelas frestas nas portas ou no brilho de uma ideia, ela está
Sempre lá, anunciando um novo começo”
Teresa Tsalaky (The Transition Witness)
Um único tema, diferentes pontos de vista.
• A produção de requisitos pode ser descrita em diferentes 
perspectivas.
• Entender que: O desenvolvimento de um software só termina 
quando o objetivo do processo é alcançado.
– Mas como terminar se não sei o objetivo?
• Como diminuir estes problemas.
– Existe métodos ?
• Ágil, Sequencial e RUP
Quinta
Um método que pode ajudar a acompanhar
Figura 6.1. Exemplo de quadro que permite a visualização do progresso do
desenvolvimento ao longo de um processo de referência baseado no Kanban
Também pode ajudar !!
• Para mitigar riscos, podemos usar um processo genérico, que 
não se propõe a cumprir o papel de uma metodologia de 
desenvolvimento completa.
– Mas...... É melhor servir como referência geral do que o 
caos!
• Podemos usar o mapeamento baseado no COCOMO II 
(Constructive Cost Model), também não podemos ignorar as 
repercussões do Manifesto Ágil, como o SCRUM por ser uma 
das metodologias ágeis mas empregadas (atualmente)
Mapeamento entre fases e objetivos gerais
Figura 6.2. Compatibilização entre diferentes
estratégias com base nos resultados que
devem entregar no tempo na forma de um
modelo de processo para referência.
Podemos destacar 3 MARCOS
1 Marco de Definição da necessidade
2 Marco de Consenso do Escopo
3 Marco de Detalhamento dos Requisitos
Importante definir o primeiro marco: necessidade
• Geralmente usa uma ferramenta da administração primitiva
– Solicitação de proposta (Request for Proposal – RFP) ou 
conhecido pela admistração pública como “Projeto básico”
• O Trabalho também acontece com o estudo de viabilidade
– Geralmente obtém no “caso de negócio” ou quando existe 
um “Plano Diretor de Tecnologia da Informação – PDTI” 
• Então Temos que:
– Definir as necessidades de negócio;
– Identificar as partes interessadas;
– Definir os casos de negócio;
– Definir o escopo da solução.
Atividades da engenharia de Requisitos
Quinta
Figura 6.3. Tarefas da Engenharia de Requisitos
As atividades de gerência de
requisitos têm como principais
objetivos:
a) Identificar a melhor forma de
comunicar os requisitos e
amaneira como será mantido o
conhecimento obtido para uso.
b) Administrar conflitos, problemas
e mudanças a fim de garantir o
acordo sobre o escopo da solução
c) Priorizar requisitos
Segundo: Consenso sobre o escopo
• Entender o problema e alinhar um escopo para o
desenvolvedor.
• Para avaliar de este Segundo Marco foi atingido requer que
definam:
– Necessidades de negócio, juntamente com as principais
restriçõe e premissas do desenvolvimento;
– As entidades importantes que integram com o sistema (de
maneira ativa ou passiva);
– Eventos mais importantes para quais o sistema deve
responder
– Os termos importantes e um glossário analisado
Quinta
Terceiro: Detalhamento dos requisitos
• Estemarco, é de fundamental importância no sucesso do 
desenvolvimento.
• A partir do marco de consolidação do escopo, o objetivo 
maior é criar uma arquitetura que sirva como linha de base 
para todo o desenvolvimento.
• Este terceiro Marco é atingido quando:
• A visão e os requisitos do produto são estáveis.
• Todos os eventos para os quais o produto deve prover 
resposta e todas as entidades que interagem com ele 
devem estar identificadas.
Técnicas
• Como são técnicas, são sugestões e não receita para o
sucesso!!
– Declaração de problemas. (págs. 127 – 129)
– Modelagem de escopo (modelagem ambiental) (pág. 129)
– Técnica: Diagrama de contexto (págs. 129 – 133)
– Técnica: Diagrama de caso de uso (págs. 133 – 135)
– Técnica: Modelo de processo de negócio(págs. 135 – 136)
Ótimo, tenho muitos métodos e técnicas. E agora qual usar ?
Quinta
Como saber com quem conversar !!!
• Agora é uma parte que requer uma visão investigativa.
– Vestir a capa de “sherlock holmes”
– Contratar o CSI.
– O que não pode é fazer premonições ....... 
• “mãe dinah”
• “Walter mercado”
• Sei, não é fácil
– Comunique-se, 
– Faça perguntas, 
– Nunca suponha, mesmo que seja óbvio.
– Tente obter uma resposta única (problema das duas portas)
Quinta
Elicitação de Requisitos
“O óbvio, Lóri, é a verdade mais difícil de se enxergar.”
Clarice Lispector LISPECTOR, C. 
Uma Aprendizagem ou o Livro dos Prazeres. 
Rio de Janeiro. 1998.
“Só profetas enxergam o óbvio.”
Nelson Rodrigues. 
Definição:
Um anglicismo do termo em inglês “elicit requirements” na
versão brasileira vira => Elicitação de Requisitos.
Nada mais é que: Levantamento de requisitos.
Quinta
Atividades do levantamento
• Preparação (ou planejamento)
• Execução
• Documentação
• Confirmação
Quinta
Preparação
• Tem como objetivo a garantir que todos os recursos
necessários estejam organizados e reservados para a sua
realização.
– Recursos: Agenda disponível das pessoas, disponibilidade
de salas para reuniões
– Obter o acordo do problema a ser resolvido
– Estabelecer consenso com o entendimento
Quinta
Execução do requisito
• Aqui o objetivo é levantar informações, de maneira proativa, juntos as 
partes interessadas. 
• Um bom uso de algumas técnicas
– Não fugir do escopo do projeto;
– Rastreabilidade de requisitos (reuso);
– Evitar os requisitos implícitos;
– Não omitir requisitos;
“Mais como vou identificar este requisito se a parte interessada não fala ?”
Não se deve esperar que a parte interessada fale tudo que é necessário, se
fosse verdade, não precisaríamos de levantar requisitos, basta um tomador
de notas. (já ouvimos isso antes... Lembra ?)
O bom analista consegue extrair estas informações da parte interessada.
Quinta
Documentação dos resultados
• É uma boa técnica utilizada no levantamento para que:
– A informação não se perca;
– O conhecimento adquirido possa ser compartilhado;
– Outras pessoas possam dar sequencia na análise;
– Seja possível confirmar, por meio desta documentação, seu 
entendimento com as partes interessadas.
• Além da documentação das informações colhidas ao realizar a 
elicitação, é importante registrar as questões que ficaram em 
aberto e dúvidas que surgiram durante estes evento que por 
ventura não puderam ser resolvidas.
Quinta
Confirmação dos resultados do requisito
• Imagine:
• “Você e seu cônjuge vão a um restaurante, fica ali alguns
minutos com o menu em mãos, logo vem um garçom e
pergunta se vocês já fizeram a escola, ele escuta suas escolhas
e sai... Algum tempo depois chega apenas um pedido... Tudo
bem você imagina que o outro irá chegar em breve..... Mais
um tempo e você pergunta ao garçom. – O meu outro pedido
ainda não chegou !. E a resposta que você ouve é. – Nossa
esqueci de pedir !”
• Vários pontos de falha poderemos elencar.
Quinta
Ajustes
• Normalmente, em uma primeira versão da documentação há 
problemas de entendimento, e o documento retorna sem 
confirmação.
– O importante e ajustar os pontos equivocados ou ausentes
• Só depois do ajuste uma nova versão e encaminhada as 
partes interessadas.
Técnica: análise de documentos
• Dificuldade em conseguir acesso as partes interessadas.
– Pouco interesse em analisar documentos onde estão
materializados as necessidades do negócio.
• Sempre há algo já documentado (por mais simples e fraco que
seja) que deve ser analisado primeiro para depois partir para
outras técnicas.
• Análise de documento: (Estudo dos documentos existentes)
– Como realizar (pág. 150)
Quinta
O que é análise de documentos
• É um meio de elicitar requisitos pelo estudo de
documentação disponível sobre uma solução existente.
– Para identificar informações relevantes para o
desenvolvimento de uma solução
• Documentação deve ter um significado mais amplo do que
especificação de requisitos.
– Identificar as necessidades de negócio
– Identificar as partes interessadas
• Sommervile cita um instrumento chamado de “interação com
partes interessadas por meio de entrevistas e observação”
Técnica: glossário
• Instrumento originalmente usado na gestão do conhecimento.
• Serve para identificar os termos chaves para o domínio do 
problema.
– No final de nosso livro de estudo existe um glossário de 
termos da engenharia de requisitos.
– Um exemplo como aplicar – pág. 157
Quinta
Técnica : Observação (etnografia)
• Usar a observação das atividades dos interessados, para 
clarear os requisitos.
– Nem todas as partes conseguem se articular ou explicar
com clareza sobre sua solicitação.
• Compreende em observar e tomar o problema como seu,
identificar os processos e dificuldades.
• Extrair os detalhes, inclusive o como se faz.
– Observação Passiva (ou invisível)
– Observação Ativa (ou visível)
Quinta
Técnica : entrevista
• Usar a forma de dialogo para buscar respostas parra um grupo de
questões previamente elaboradas.
• Quando se tem uma resposta, normalmente e utilizada a mesma
resposta para elaborar uma outra pergunta par que possa ser
clareada a sua solução.
• Cuidado com a primeira impressão.
– Seja um bom ouvinte
– Vá de coração aberto: livre-se de preconceitos
– Busque fatos, mas também opiniões.
Lembre “A primeira impressão é a que fica”
Quinta
Formato da entrevista
Figura 7.2. Nas entrevistas não estruturadas, o roteiro é apenas um guia para o 
entrevistador, mas não o obriga a seguir uma sequência prévia de perguntas
Tipos básicos de estrutura da entrevista
Como preparar a entrevista
• Págs. 169 – 173
• Técnica 5W + 3H
– What (o quê), Who (quem), Why (por quê), Where (onde), 
When (quando)
– How (como) e How Much (quanto) 
• Tipos de questões
– Abertas
– Fechadas
• Formato da entrevista
– Formal
– Informal
Quinta
Técnica : pesquisa/questionário
• Consiste em aplicação de questionário para ser respondido.
• Diferente da entrevista, pois não há interação
• Risco
– Omissão de informação
• Aplicado quando há um conhecimento pleno do negócio de 
ambas as partes.
Quinta
Como realizar a pesquisa
• Selecionar o publico
• Preparação de questionário
– Questões com respostas limitadas
– Questões com respostas livres
• Mesmo com muito cuidado na elaboração do questionário, é
muito importante que ele seja testado antes de ser
distribuído.
• Nada serve um questionário bem elaborado se ele não
alcança o publico alvo.....
Agora estamos no 
fim.....
...Falta pouco...
Seja forte !!!
Análise de requisitos
“Noite, a amada. Noite, quando palavras se dissolvem e as 
coisas tornam-se vivas. Quando a destrutiva análise diária está 
completa, e tudo que é realmente importante se torna inteiro e 
razoável novamente.Quando o homem junta outra vez o seu ser 
fragmentado e cresce com a calma de uma árvore.”
Antoine de Saint-Exupéry
Descoberta tardia que ainda falta muito
• Quando o produto não atende às necessidades e as partes
interessadas só descobrem quando executam testes de
aceitação ou alguns dias antes de instalar em produção.
– Isso é uma das expectativas mais frustrantes para todos.
• Um fenômeno comum
– O projeto apresenta um caminho de conclusão final do
projeto, quando na realidade próximo da metade.
• Este problema ocorre quando se esclarece qual o marco
inicializado para indicar 50% concluído e outro para avaliar
100%.
lustrando o paradoxo
Visão geral da análise de requisitos
• A análise de requisitos é o olhar mais de perto,
especificamente cada pedaço de informação revelado na
elicitação e sobre como eles se relacionam entre se em
conjunto.
Sexta
Análise de Requisitos
Sexta
Figura 8.3. Dinâmica da interação entre elicitação e análise, onde os produtos de 
uma são insumos para a outra
Então
• Análise de requisitos transforma a informação presente nos
requisitos das pastes interessadas e na necessidade de
negócio em diferentes processos.
– Exame da informação
– Decomposição da informação;
– Síntese da informação
Sexta
A análise
• Porque ?
– Aumentar o entendimento atual da informação, completa-
la e melhora-la.
• Como realizar ?
– Uso da técnicas
Os requisitos das partes interessadas são difusos, fragmentados
e escondem muitas questões em aberto.
Sexta
Organizar a partir do exame, decomposição e síntese
• O exame em discussão busca identificar requisitos que
agregam vários objetivos do usuário.
• Garante elucidar questões encobertas
Sexta
Tratar decisões que impactam o escopo
• Deve ser acordado qual opção melhor adequa-se às
necessidades de negócio e restrições do domínio do
problema.
• São decisões que implicam em:
– Identificar tarefas;
– Consolidar tarefas;
– Transferir parte do processamento de tarefas.
Sexta
Tarefas (Identificar ou descrever)
• Identificar o comportamento das tarefas
• Decompor as informações
• Síntese da informação
Sexta
Modelar e usar modelos para refinar a informação
• O que é modelar ?
• Porque modelagem ?
• Como Realizar a modelagem ?
– Modelos preexistentes
– Modelos a elaborar
– Tipos quanto a forma
– Tipos quanto a informação
Sexta
Especificar para documentar os requisitos
• A modelagem coloca a ênfase na revelação dos requisitos e a
comunicação ente as partes.
• A Especificação tem a ênfase na transmissão da informação
para a equipe de desenvolvimento, mesmo que exija a
produção compreensível para todas as partes
Sexta
O que é especificação
• Especificação de requisitos tem papel de documentar os tipos 
de requisitos.
• Formatar a documentação resultante da especificação.
– Agora estamos falando em formatar !!!!!
• Por que especificar ?
– Veja uma relação bem completa que o PMI – 2015 
“Project Management Institute” pág. 201
Sexta
Tentando fazer um exercício
Bernadinho, (Treinador de vôlei) deseja levar um Notbook para os jogos, a fim de
obter:
- controle do placar.
- controle dos pontos de cada partida, identificando-os como:
Ponto de saque; Ponto de ataque (quando a vantagem estiver com o time
adversário), ponto de contra-ataque (quando a vantagem estiver com o próprio
time); Ponto de bloqueio; Erro do adversário. No caso de bloqueio deve cadastrar
se é individual, duplo ou triplo.
São expectativas de Bernadinho para a implantação dessa aplicação:
- cadastrar o nome de todos os jogadores do time e o número de suas camisas;
- Para cada jogador, cadastrar a data e hora do jogo, o local o nome do time
adversário, os nomes do juiz e juiz auxiliar.
- a aplicação dever exibir para controle em cada set, o placar que pode ser alterado
pelo auxiliar técnico, informando quem fez o último ponto e o tipo do ponto. No caso
do ponto ser do time adversário, basta identificar o tipo do ponto.
- ao final de um jogo, o sistema deve exibir a lista dos maiores pontuadores e o
somatório de pontos, por tipo e o jogo
Como elaborar
• Agora depois do exercício fica tudo mais fácil.
• Bem aqui, vamos deixar o nosso livro de lado...
• Não existe um formato único definido, vários autores descrevem
muitos exemplos de modelo.
• Nem as normas formalizam isso, pois não é o formato que diz se o
requisito será feito com qualidade ou não.
– Porém, precisamos de padrões – organizar os métodos para
aplicar as técnicas.
• Mesmo assim vamos ver alguns modelos e definir o nosso.
Sexta
Modelo do livro
• Podemos ver que o nosso livro de estudo sugere na página 203 um
exemplo simples.
• No modelo atual do JIRA, não podemos deixar de apresentar alguns
requisitos bem elaborado, que pode nos servir de exemplo positivo,
e usar como estudo de caso:
– https://uniksa.atlassian.net/browse/PRJBNC0071-11
– https://uniksa.atlassian.net/browse/PRJBNC0071-12
• Agora existem muitos outros exemplos bons, só citei estes mais 
recentes.
• Vamos ver alguns templates . . . . .
Sexta
Modelo de Caso de Uso - Simples
Sexta
Modelo de Caso de Uso - Detalhado
• Contém:
– Identificação do ator que iniciou o caso de uso
– Objetivo
– Nível
– Pré-requisitos (se houver) do caso de uso
– Condições de disparo (triggers)
– Descrição textual do:
• Fluxo normal
• Fluxos alternativos (se houver)
Sexta
O modelo que usamos no JIRA
• OBJETIVO
• DESCRIÇÃO
• PRÉ-CONDIÇÕES
• PÓS-CONDIÇÕES
• CENÁRIO ATUAL
• NOVO CENÁRIO
Sexta
Podemos montar um que nos atenda
• Então, percebemos que o formato não é muito relevante.
• E sim o conteúdo e a qualidade do requisito que será descrito.
• Lembrando que, quando o analista desenvolvedor pede
esclarecimento de duvidas sobre o objetivo do requisito
diretamente ao Analista de requisitos e este comportamento
for muito frequente.
– Significa que existe algo errado em algum processo que
não foi devidamente explicitado no requisito.
• Hora de rever o entendimento com a parte interessada.
Sexta
Este assunto exige
um estudo constante.
Não pare de estudar.
Obrigado