Levantamento_de_requisitos

Prévia do material em texto

Levantamento de Requisitos
Bibliografia
� PAULA-FILHO, Wilson de Pádua. Engenharia 
de Software: Fundamentos, Métodos e 
Padrões. 2ª ed., Rio de Janeiro: LTC - Livros 
Técnicos e Científicos, 2003, capítulo 5.
� PRESSMAN, Roger S. Engenharia de Software. 
5ª ed., Rio de Janeiro: McGraw Hill, 2002, 
capítulos 10 e 11.
� IEEE. SWEBOK: Guide to the Software 
Engineering Body of Knowledge. 2004, 
capítulo 2. 
Levantamento de Requisitos
� Conjunto de atividades da Engenharia de 
Requisitos que tem como objetivo 
descobrir:
� mais informações sobre o domínio da 
aplicação;
� quais são os efeitos que o sistema deve ter;
� sobre o domínio do problema;
� restrições relacionadas ao produto de software.
� Outras terminologias:
� elicitação de requisitos;
� descoberta de requisitos.
Dimensões do Levantamento 
de Requisitos
Dimensões do Levantamento 
de Requisitos
� Compreender o domínio da aplicação:
� conhecimento geral de onde o sistema será
implantado.
� Compreender o problema a ser resolvido:
� entendimento dos detalhes específicos do 
problema do cliente e dos usuários.
� Compreender o contexto de negócio:
� entendimento de como os sistemas 
interagem e contribuem de forma geral com 
os objetivos do negócio do cliente.
� Compreender as necessidades e 
restrições dos interessados.
� Clientes e usuários:
� nem sempre sabem;
� o que um produto de software pode oferecer;
� podem não saber exatamente o que 
desejam;
� podem ser relutantes em tomar decisões;
� geralmente expressam os requisitos;
� em seus próprios termos.
� Problemas com a própria linguagem utilizada:
� ambígua, mesmos termos com significados 
diferentes, etc. 
� Usuários podem ter dificuldades;
� para descrever suas tarefas.
Dificuldades
Dificuldades
� Especialistas no domínio da aplicação podem 
entender tão bem a área;
� que não tornam todos os requisitos explícitos.
� Diferentes interessados no produto de software;
� podem ter requisitos conflitantes.
� O escopo do sistema pode não estar bem-
definido.
� Os requisitos podem mudar durante o projeto de 
desenvolvimento de software:
� novos interessados no produto de software podem 
surgir;
� o processo de negócio pode mudar.
Dificuldades
� Fatores políticos e organizacionais;
� também podem influenciar os requisitos do sistema.
� Por não ser a especialidade dos analistas de 
requisitos;
� as características do domínio da aplicação podem não 
ser entendidas de forma suficiente;
� para produzir uma especificação de requisitos 
satisfatória.
� Analistas de requisitos podem não dominar;
� o próprio processo de levantamento de requisitos do 
software.
� Analistas de requisitos podem concentrar-se em 
informações desnecessárias neste momento;
� relacionadas, por exemplo, ao projeto arquitetural do 
sistema.
O que Deve ser Levantado?
� Objetivo do sistema;
� Vocabulário do domínio da aplicação;
� Requisitos:
� funcionais;
� de projeto;
� de processo;
� não-funcionais;
� Critérios de aceitação desses requisitos.
O que Deve ser Levantado?
� Objetivo do sistema:
� descrição sucinta e em alto nível sobre:
� o que queremos que o sistema faça;
� como o sistema contribuirá com os objetivos do 
trabalho.
� indica a motivação para o desenvolvimento 
do produto de software.
� Stakeholders devem atribuir valores aos 
objetivos do sistema;
� relativos à prioridade.
O que Deve ser Levantado?
� Vocabulário do domínio da aplicação:
� termos utilizados na descrição dos requisitos 
do sistema.
� O analista de requisitos precisa adquirir 
conhecimento sobre o domínio da 
aplicação, o que possibilitará:
� inferir conhecimento tácito;
� que os stakeholders não explicitam;
� avaliar requisitos conflitantes.
O que Deve ser Levantado?
� Requisitos:
� funcionais;
� de projeto;
� de processo;
� não-funcionais.
� Como saber se cada requisito foi 
satisfeito?
� É necessário estabelecer critérios de 
aceitação para os requisitos.
� Critérios de aceitação para requisitos não-
funcionais;
� devem ser mensuráveis.
� Stakeholders;
� Ambiente operacional:
� requisitos podem ser derivados do 
ambiente no qual o software
executará.
� Requisitos desse tipo podem afetar a 
viabilidade e custo do software;
� e restringir as opções de solução.
� Ambiente organizacional;
� Documentos da empresa cliente;
Fontes de Requisitos
� Normas, legislação, etc;
� Produtos e sistemas já existentes:
� produtos concorrentes;
� sistemas da empresa cliente;
� com os quais o sistema a ser desenvolvido 
deverá interagir;
� versões anteriores do sistema que será
desenvolvido.
Fontes de Requisitos
� É toda pessoa que tem interesse no 
produto de software:
� clientes;
� usuários finais;
� especialistas do domínio da aplicação;
� auxiliam na obtenção de conhecimento tácito;
� que os usuários não explicitam;
� departamento de marketing;
� desenvolvedores;
� engenheiros envolvidos na manutenção e 
operação de outros sistemas relacionados;
� reguladores.
Stakeholder
� Stakeholders representam 
diferentes maneiras de se olhar para 
um problema;
� ou pontos de vista diferentes.
� Uma análise com várias 
perspectivas é importante;
� já que não há uma única forma 
correta para analisar os requisitos do 
sistema.
Stakeholder
� É a forma mais comum de 
levantamento de requisitos.
� O objetivo de uma entrevista é:
� obter informações do entrevistado, 
sobre:
� o domínio da aplicação;
� o processo de negócio existente;
� um determinado assunto ou problema;
� para entender os problemas reais e soluções 
potenciais, da perspectiva dos stakeholders do 
sistema.
Técnicas de Levantamento de Requisitos –
Entrevista com Stakeholders
� Cada stakeholder fornece informações;
� sobre sua área de interesse ou 
especialidade.
� Pode ser individual ou em grupo:
� em grupo:
� permite a comprovação imediata de 
discordâncias.
� Não se deve assumir nenhum 
conhecimento prévio sobre o problema;
� chama-se essa postura de “ignorante 
inteligente”.
Técnicas de Levantamento de Requisitos –
Entrevista com Stakeholders
� Diretrizes para uma Boa Entrevista:
� desenvolva um Plano Geral de Entrevistas:
� quem entrevistar?
� consulte o organograma da empresa cliente para 
definir as áreas envolvidas e a ordem das entrevistas.
� planeje a entrevista:
� defina seu escopo;
� obtenha e estude os documentos necessários antes 
da entrevista;
� defina os objetivos da entrevista, os pontos que 
serão tratados e seu roteiro;
� deve-se preparar as perguntas antecipadamente;
� defina o perfil necessário para o entrevistado.
Técnicas de Levantamento de Requisitos –
Entrevista com Stakeholders
� Diretrizes para uma Boa Entrevista:
� durante a entrevista, recomenda-se:
� ser imparcial;
� não influenciar o entrevistado;
� evitar interrupções por terceiros;
� evitar criar atritos recíprocos e bloqueios de 
comunicação;
� evitar discussões desnecessárias;
� organização.
� sugere-se elaborar:
� um resumo oral da entrevista, ao final;
� um resumo escrito, que deve ser encaminhado 
para o entrevistado, para sua validação.
Técnicas de Levantamento de Requisitos –
Entrevista com Stakeholders
Técnicas de Levantamento de 
Requisitos – JAD
� Joint Application Design.
� Técnica desenvolvida pela IBM;
� orientada ao trabalho em grupo;
� decisões baseiam-se em consenso;
� considerando que um grupo de pessoas pode obter 
melhores resultados para seu problema;
� do que trabalhando individualmente.
� Em geral, resulta em um conjunto de 
requisitos mais rico e consistente;
� do que o usualmente alcançado através de 
entrevistas.
Técnicas de Levantamentode 
Requisitos – JAD
� O processo é altamente estruturado.
� Cada sessão tem uma finalidade previamente 
definida.
� O líder da sessão conduz o grupo para o 
objetivo;
� segundo o indicado na agenda.
� Permite o levantamento e refinamento de idéias;
� que dificilmente seriam obtidas através de entrevistas.
� Requisitos conflitantes são detectados mais 
cedo;
� permitindo economia de tempo;
� pela resolução mais rápida de divergências.
� Técnica em que os diversos 
stakeholders do sistema se reúnem;
� para levantar idéias e emitir opiniões 
sobre o sistema.
� Na primeira sessão de brainstorming, 
idéias são apenas levantadas;
� não se deve julgar as idéias;
� é proibido criticar.
� Sessões posteriores são usadas;
� para priorizar o que foi levantado.
Técnicas de Levantamento de 
Requisitos – Brainstorming
Técnicas de Levantamento de 
Requisitos – Cenário
� Meio que permite ao analista de 
requisitos prover um contexto para a 
formulação de questões a respeito:
� da execução das tarefas do usuário;
� dos requisitos do sistema.
� Permite também que questões como 
“e se” e “como isso é resolvido?”
sejam formuladas.
� Perguntas são distribuídas aos 
stakeholders do sistema.
� Resultados são obtidos por escrito.
� Em geral, é difícil elaborar 
questionários eficazes.
� Técnica mais aplicável em mercados 
específicos;
� onde perguntas são bem definidas.
Técnicas de Levantamento de 
Requisitos – Questionário
Técnicas de Levantamento de 
Requisitos – Protótipos
� São ferramentas para o levantamento e 
validação de requisitos.
� Criação de uma versão inicial e, em 
geral, parcial do sistema;
� útil para clarear requisitos mal-definidos.
� A idéia é desenvolver um protótipo o 
mais cedo possível;
� e colher feedback dos stakeholders.
� Atuam de forma semelhante a cenários;
� provendo um contexto;
� em que os usuários podem melhor compreender de que 
informações o analista de requisitos necessita.
� Baseados no principio IKIWISI:
� “I’ll know it when I see it”. (Conhecerei quando vê-lo)
� As pessoas têm mais facilidade em reconhecer a 
solução correta;
� do que em descrevê-la.
� Não precisam ser:
� funcionais;
� visualmente fiéis ao produto final.
� Precisam demonstrar como o usuário irá
interagir com o sistema.
Técnicas de Levantamento de 
Requisitos – Protótipos
� Vale tudo:
� protótipos de papel;
� desenhos de telas;
� páginas HTML estáticas.
� O importante é que o cliente saiba dizer;
� se é ou não aquele o sistema que ele precisa.
� Não serve para avaliar a correção e 
precisão dos requisitos.
� Deve-se jogar fora o código do protótipo 
descartável!
Técnicas de Levantamento de 
Requisitos – Protótipos
Técnicas de Levantamento de 
Requisitos – Observação
� Técnica em que o analista de 
requisitos busca informações na 
documentação existente na 
empresa cliente:
� relatórios;
� manuais;
� normas; etc.
Técnicas de Levantamento de 
Requisitos – Estudo de Documentos
� Quais são alguns motivos pelos quais você e 
seus colegas usariam o novo sistema?
� Que objetivos você tem em mente que esse 
sistema o ajudaria a cumprir?
� Que aspecto do sistema você acha mais 
interessante?
� Que aspecto terá mais valor para você? E menos 
valor?
� Que problemas você espera que esse sistema 
resolva para você?
� Que palavras você usaria para descrever o 
sistema?
� Como você vai julgar se o sistema é um 
sucesso?
Perguntas para se Levantar 
Requisitos
� Em que aspectos você imagina que o sistema 
deva ser semelhante à forma como você 
trabalha hoje? Como ele deve ser diferente?
� Que aspectos dos seus processos de negócios 
você quer manter? Quais você quer substituir?
� Que eventos externos estão associados ao 
sistema?
� Você pode descrever o ambiente onde o sistema 
vai ser usado?
� Algumas partes do produto são mais importantes 
que outras por motivos de desempenho, 
segurança, robustez, disponibilidade, ou alguma 
outra característica?
� Há alguma restrição ou regra a qual o sistema 
deve estar de acordo?
Perguntas para se Levantar 
Requisitos