A maior rede de estudos do Brasil

Grátis
98 pág.
Engenharia De Requisitos Software Orientado Ao Negocio

Pré-visualização | Página 1 de 4

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,

Crie agora seu perfil grátis para visualizar sem restrições.