Aula4 levantamento requisitos

Post on 24-Jan-2015

267 views 0 download

description

 

Transcript of Aula4 levantamento requisitos

Engenharia de Software

Aula 4 – Levantamento de Requisitos do Sistema

Profa. Dra. Judith PavónUniversidade Salvador – UNIFACS

2012

Objetivo da aula

2

O objetivo desta aula é apresentar algumas técnicas de Levantamento de Requisitos.

3

Conteúdo

1. Análise do Problema

2. Técnicas de levantamento de requisitos

3. Casos de Uso

Análise do ProblemaDomínio do Problema

Conceitos, processos,necessidades, objetivos,termos..

Clientes, usuários, etc.

Analistas

Torna-se nosso problema,compreender o problema

dosusuários (de

negócio/técnicos)

Análise do Problema Análise de problemas - processo de compreender um

problema e propor soluções para resolver esse problema. Entender o problema a ser resolvido antes de iniciar o

desenvolvimento da aplicação. Quando se considera este tópico (análise do problema) como

principal preocupação no levantamento de requisitos denomina-se “processo de descoberta de requisitos orientado ao problema”.

acordar na

definição do

problema

entender as causas

do problema

identificar os

stakeholders

definir as fronteira

s da solução

identificar as

restrições da

solução

Análise do ProblemaAcordar na definição do

problema Como formular um problema?

O Problema de Descrição do Problema

Afeta Os Stakeholders afetados pelo problema

Resultando em Qual é o impacto do problema?

Benefícios Indicação da solução proposta e uma lista de benefícios chaves

Análise do ProblemaAcordar na definição do problema Exemplo de formulação do problema

O Problema de Solução inadequada e fora dos prazos das requisições de serviço dos clientes

Afeta Nossos clientes, equipe de suporte ao cliente, outros técnicos

Resultando em Insatisfação do cliente e dos empregados, sentimento de que qualidade dos serviços é inadequada, e queda nas vendas.

Benefícios Solução: prover acesso em tempo real a uma base de dados de problemas à equipe de suporte.

Benefícios: rápido acesso à informação, agilização dos processos operacionais.

Entender as Causas do Problema

Análise da raíz do problema:Forma sistemática de descobrir o que está por trás de um problema

ou dos seus sintomas

Entender as Causas do Problema

atrasos na entrega dadocumentação do projeto

os conteúdos estão dispersos

pouco tempo para escrever os relatórios

causa X

causa Ycausa Z

Exemplo de técnica: diagrama de espinha de peixe

Entender as Causas do Problema Quais são as causas do problema?

A maior parte das vezes não vale a pena considerar TODAS as causas que são raiz

do problema!!!... (???)

Porque os custos seriam muito superiores aos benefícios...

Como saber quais as causas que vale a pena considerar na resolução do problema?

Entender as Causas do Problema Selecionar as causas a considerar:

Recolher dados sobre a incidência de cada causa.

Desenhar um diagrama de Pareto.

Entender as Causas do Problema

dispersão de conteúdoscausa x

causa ycausa z

05

101520

25

30

35

40

45

50

diagrama de Pareto das causas raíz

tempo de escrita do relatório

Consiste em um gráfico de barras que ordena as freqüências das ocorrências da maior para menor e permite a localização das causas

mais freqüentes.

Identificar os stakeholders

Compreender as necessidades dos interessados no sistema é um fator decisivo no desenvolvimento de uma solução efetiva para um problema

Quem são os usuários do sistema? Quem é o cliente (comprador) do sistema? Quem será afetado pelas saídas que o sistema produz? Quem fará a manutenção do sistema? ...

Definir as Fronteiras da Solução

Usuários

SOLUÇÃO

OUTROS

SISTEMAS

E/S

E/S

Identificar as Restrições da Solução

Identificar e compreender as restrições impostas ao sistema.

Restrições

Econômicas; Políticas; Tecnológicas; Sistemas existentes; Ambiente; Recursos.

Entendendo as Necessidades dos Stakeholders

Diferentes Necessidades dos Stakeholders Os processos de engenharia de requisitos são dominados por fatores

humanos, sociais e organizacionais porque eles sempre envolvem um conjunto de partes interessadas com backgrounds diferentes e com objetivos organizacionais e individuais diferentes

As partes interessadas (stakeholders) pelo sistema podem ter uma variedade de background técnico e não técnico e de diferentes disciplinas.

gestão

usuáriosfinais

clientes

analistas

negociação,aprendizage

m

documento de requisitos

Entendendo as Necessidades dos Stakeholders

Características dos Stakeholders mais importantes:

Conhecimento do assunto;

Poder de decisão;

Objetividade;

Representatividade.

Entendendo as Necessidades dos Stakeholders

Fatores que influenciam os requisitos:

Personalidade e status dos stakeholders.

Os objetivos pessoais dos indivíduos dentro da empresa.

O grau de influência política dentro de uma organização.

Entendendo as Necessidades dos Stakeholders

Por que capturar ou levantar requisitos é tão difícil?

Usuários são uma fonte imperfeita de informação:

Vários usuários...inconsistências!

Falta da visão geral do processo.

Falta da visão técnica.

Entendendo as Necessidades dos Stakeholders

“Conversa com o alienígena”

Dificuldades de comunicação entre usuários e desenvolvedores.

Mundos diferentes, culturas e termos distintos.

Comunicação gera problemas que afetam diretamente os requisitos no meio do caminho.

O quê fazer? Buscar aprender sobre a área

de conhecimento das pessoas do outro grupo.

Stakeholder Desenvolvedor

Entendendo as Necessidades dos Stakeholders

Problema Proposta de Solução

Usuários não sabem exatamente o que querem ou sabem mas não são capazes de organizar suas idéias para explicar aos desenvolvedores.

Reconheça o usuário como o especialista da área e aprecie seu conhecimento; tente meios coletivos de identificação de requisitos.

Usuários somente descobrem o que realmente querem quando os desenvolvedores lhes mostram algum resultado preliminar.

Gere protótipos rápidos antes de desenvolver o sistema propriamente dito, apenas para validação dos usuários.

Os analistas acham que entendem melhor os problemas do usuário do que o próprio usuário.

Aproxime o analista do usuário de forma que este verifique se seu conhecimento procede neste caso.

Todos acreditam que existem razões políticas por trás das ações dos outros.

Seres humanos são seres políticos: devemos aprender a lidar com estes aspectos.

Identificação da Fonte de Informação

Identificação das fontes de informação:

Stakeholders (Clientes, Usuários, Patrocinadores)

Outras fontes de Informação:

Documentação do macro-sistema; Políticas; Manuais; Memos, atas, contratos... Livros sobre tema relacionado; Outros sistemas da empresa; Outros sistemas externos.

Identificação da Fonte de Informação

Priorizar as fontes de informação:

Stakeholders mais importantes;

Documentos mais mencionados ou utilizados;

Rede de comunicações entre os componentes do macro-sistema.

Técnicas de Levantamento (Elicitação)

Entrevistas e Reuniões. Análise de Documentos. Brainstorm. Prototipagem. Workshop de Requisitos.

JAD. Questionários. Observação Direta. Casos de Uso. Role Playing. Storyboard.

Técnicas de LevantamentoEscrever requisitos Requisitos são geralmente escritos como textos em linguagem natural

complementados por diagramas e modelos. Geralmente são iniciados com a frase: “O sistema deve permitir.....”

Recomendações Evitar cláusulas condicionais complexas que podem confundir. Use a linguagem de forma simples, consistente e concisa. Use sentenças diretas e objetivas. Defina requisitos verificáveis. Evite ambigüidades. Evite sentenças muito longas. Complemente a linguagem natural com outras descrições de requisitos. Não assuma que todos os leitores dos requisitos tenham o mesmo

background e usem a sua terminologia. Permita tempo para revisão e ser for necessário reescreva os requisitos.

Casos de Uso Os casos de uso referem-se aos serviços ou processos

de negócio que podem ser utilizados de alguma maneira pelos usuários do sistema, como emitir um relatório ou comprar um produto.

Os casos de uso são utilizados para expressar e documentar o comportamento ou funções do sistema.

Um modelo de casos de uso é composto pelo diagrama de casos de uso e a documentação dos elementos do modelo,

Caixa Eletrônico

EfetuarSaque

ConsultarSaldo

O Hardware é a fronteira

Cliente

ConsultarExtrato

Gerente

Consultar Saldo- Breve descrição - Fluxo de eventos

Efetuar Saque- Breve descrição - Fluxo de eventos

Consultar Extrato- Breve descrição - Fluxo de eventos

Dúvidas

27