Levantamento de Requisitos

Eveline Alonso VelosoPUC-Minas

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.

Transparências da professora Maria Augusta Vieira Nelson – PUC-Minas.

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 Levantamento de 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”. 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