Levantamento de Requisitos

Apresentação em tema: "Levantamento de Requisitos"— Transcrição da apresentação:

1 Levantamento de Requisitos
Eveline Alonso Veloso PUC-Minas

2 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.

3 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.

4 Dimensões do Levantamento de Requisitos

5 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.

6 Dificuldades Clientes e usuários: Usuários podem ter dificuldades;
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. “Análise de Sistemas é uma forma de comunicação entre estranhos.” (Tom de Marco) Diferença de vocabulários e experiências.

7 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.

8 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.

9 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.

10 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.

11 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.

12 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.

13 Fontes de Requisitos 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;

14 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.

15 Stakeholder É 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.

16 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. The software engineer needs to identify, represent, and manage the “viewpoints” of many different types of Stakeholders.

17 Técnicas de Levantamento de Requisitos – Entrevista com Stakeholders
É 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. O analista de requisitos pode utilizar diferentes técnicas simultaneamente durante o levantamento dos requisitos de um único sistema.

18 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”.

19 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.

20 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.

21 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.

22 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.

23 Técnicas de Levantamento de Requisitos – Brainstorming
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.

24 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.

25 Técnicas de Levantamento de Requisitos – Questionário
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.

26 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.

27 Técnicas de Levantamento de Requisitos – Protótipos
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.

28 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!

29 Técnicas de Levantamento de Requisitos – Observação
Técnica em que o analista de requisitos se insere no meio onde funcionará o sistema; e observa o que acontece: de forma passiva: o observador não interfere; de forma ativa: o observador solicita que se demonstre: como algo é feito; o que acontece em certas situações; criando cenários para facilitar o entendimento dos envolvidos.

30 Técnicas de Levantamento de Requisitos – Estudo de Documentos
Técnica em que o analista de requisitos busca informações na documentação existente na empresa cliente: relatórios; manuais; normas; etc.

31 Perguntas para se Levantar Requisitos
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?

32 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?