A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Levantamento de Requisitos Eveline Alonso Veloso PUC-Minas.

Apresentações semelhantes


Apresentação em tema: "Levantamento de Requisitos Eveline Alonso Veloso PUC-Minas."— 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 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 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

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

14 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

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

16 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

17 É 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

18 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

19 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

20 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

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

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

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 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: Ill 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

28 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

29 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. Técnicas de Levantamento de Requisitos – Observação

30 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

31 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

32 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


Carregar ppt "Levantamento de Requisitos Eveline Alonso Veloso PUC-Minas."

Apresentações semelhantes


Anúncios Google